Thanks to all!
My problem is to try to capture console output on machines that reboot unattended. (Original posting at end of summary)
Responses were of 3 varieties:
1> To log all messages for machine A, including those before the rc gets
1> run conserver on a machine B. Connect the serial ports of A and B.
1> Configure A to use the serial port as its console. conserver will then
1> log everything A spits out.
1> We're planning to go to this configuration, upon finding a decent way
1> of hooking several serial ports to a machine - preferably a sun3, but
1> not necesarily. It has the nice side effects of:
1> - requiring fewer tty's around - relatively expensive (though not
1> much), and they take up room
1> one can do an L1-a equivalent from home, if a machine gets silly.
2> Have the console port be the serial port.
2> Get an ALM-2 board, and connect a small GUI Sun box (IPC) to all
2> of the servers in question using a Console Server product (or
2> just tip to each one in a seperate command tool).
2> Another way to do it is to log all console messages out the serial port
2> as before (change eeprom settings and all that stuff), and connect it
2> to a terminal server or printer.
3> How about an old fashioned paper trail?
These were all of the variety: why don't you use syslog?
I DO USE SYSLOG! In fact, I have one machine set up to log EVERYTHING:
*.emerg;*.alert;*.crit;*.err;*.warning;*.notice;*.info;*.debug;mail.none ifdef(`LOGHOST', /var/log/UOPlogs/everything, @loghost)
I have tested the configuration using logger (it is working). However,
the bulk of the logged messages come from "cron", "login", "su", and
"automount". Most processes don't seem to use the syslog facility.
The only boot messages that get logged are the "dmesg" messages.
TRY THIS SUGGESTIONS:
4> I use method 1 (exec > /rc.log 2>&1; set -x) if debugging problems ...
5> I haven't tried this, but it seems like it should work ... ;^)
5> It's a nice sh feature I use frequently in dumpscripts and the like.
5> > intr mount -at 4.2
5> > echo -n 'checking quotas: '
5> > intr quotacheck -a -p
5> > .
5> > .
5> > .
5> } | tee -a /var/adm/messages
I can now also add my own experiences to this category, as I tried my
"Way 2" ( changing the rc.local invocation in /etc/rc to:
"sh /etc/rc.local | tee -a /var/adm/messages" ). It doesn't work! The
machine hangs at the point in which /etc/rc.local should return control
to /etc/rc. 8-(
I don't really think I can justify hardware acquisition at this time,
and, anyway, I was hoping for a solution that would work for every
machine. I think I will try Number 4 next...
Mucho Thanks To:
>From: Dan Stromberg - OAC-DCS <firstname.lastname@example.org>
>From: Pat Cain (Denver) <email@example.com.COM>
>From: ebumfr@EBU.ericsson.se (Mike Rembis 66520)
>From: Giles.Carre@cri.ens-lyon.fr (Giles Carre)
>From: green@Kodak.COM (Russell Green)
----- Begin Included Message -----
>From rjcronin Tue Sep 28 16:20:03 1993
Subject: Capturing boot output
SunOS 4.1.1 and 4.1.3 on SPARCstations...
We regularly reboot our machines unattended, and never get much
opportunity to see error messages generated by services started up in
the /etc/rc* files. /var/adm/messages only records the dmesg stuff.
I am thinking of adjusting the /etc/rc file to append standard output to /var/adm/messages, as soon as the 4.2 filesystems are mounted r/w. I can think of 2 ways to do this:
intr mount -at 4.2
exec >> /var/adm/messages
tail -f /var/adm/messages > /dev/tty &
echo -n 'checking quotas: '
intr quotacheck -a -p
sh /etc/rc.local | tee -a /var/adm/messages
Way 2 only captures /etc/rc.local stuff.
Both ways seem kludgey and ill-advised.
Can anyone recommend a good way to capture console start-up messages?
Alternatively, can anyone point out why I should not pursue either
Way 1 or Way 2?
Thanks, and will summarize,
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:19 CDT