Even though daemons ought to log to to syslog, not to stderr,
and even though serial consoles exist - did it ever happen to you
that you sat in front of the console of a server, trying to scroll up,
musing "what might the output of /etc/rc have been"?
Or that you were logged into a remote server via SSH,
and got quite curious in the same respect?
Admittedly, the following is rather hackish, and it only saves
output after the local file systems have been mounted.
A cleaner way might be to set up two pipe(2)s in sbin/init.c:runcom
before the fork, dup2(2) their write ends to stdout and stderr in
the runcom child before execv(2), poll(2) their read ends in the
original init process, always instantly copying the data to the
original stdout and stderr file descriptors, but also caching it
in a local buffer. The rc script should print an unambiguous
message as soon as the local file systems are mounted, an when
init sees that message, it should start flushing the local buffer
to /var/log/rc.log.
Am i missing some clever way to capture the /etc/rc output
short of setting up a serial console? Or do you consider that
output to be so boring that you just never wanted it?
Any thoughts?
Index: etc/rc
===================================================================
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.321
diff -u -r1.321 rc
--- etc/rc 11 Dec 2008 15:44:00 -0000 1.321
+++ etc/rc 14 Feb 2009 16:10:33 -0000
@@ -241,6 +241,11 @@
mount -uw / # root on nfs requires this, others aren't hurt
rm -f /fastboot # XXX (root now writeable)
+rm -f /var/log/rc.log /var/run/rc.fifo
+mkfifo /var/run/rc.fifo
+tee /var/log/rc.log < /var/run/rc.fifo &
+exec >> /var/run/rc.fifo 2>&1
+
random_seed
# pick up option configuration
@@ -809,4 +814,5 @@
echo 'starting xdm...'; /usr/X11R6/bin/xdm ${xdm_flags}
fi
+rm -f /var/run/rc.fifo
exit 0
