Linda Walsh wrote:
James Knott wrote:
Linda Walsh wrote:
Is there any easy way to save the boot-time output after the kernel
has booted and init has started running '/etc/rc.d/boot'?
Try the dmesg command.
I would, but it doesn't help. When "boot" starts (1st script
called by init), it redirects stdout and stderr to /dev/console.
#
# Set I/O of this script and its childs to console
#
exec 0<> $CONSOLE 1>&0 2>&0
Now, according to the bash manual:
Duplicating File Descriptors
The redirection operator
[n]<&word
is used to duplicate input file descriptors.
If word expands to one or more digits, the file
descriptor denoted by n is made to be a copy of
that file descriptor. If the digits in word do
not specify a file descriptor open for input,
a redirection error occurs. If word evaluates
to -, file descriptor n is closed. If n is not
specified, the standard input (file descriptor
0) is used.
The operator
[n]>&word
is used similarly to duplicate output file
descriptors. If n is not specified, the
standard output (file descriptor 1) is used.
If the digits in word do not specify a file
descriptor open for output, a redirection error
occurs. As a special case, if n is omitted,
and word does not expand to one or more digits,
the standard output and standard error are
redirected as described previously.
#
# Set I/O of this script and its childs to console
#
exec 0<> $CONSOLE 1>&0 2>&0
So..it doesn't redirect stdout and stderr to /dev/console,
it COPIES the stdout (fd1) and stderr (fd2) to fd0 (stdin),
and uses fd0 for communication both from AND TO the console.
I think something can be done by duplicating fd1 and fd2
AGAIN, but to fd3, like this
#
#
# Set I/O of this script and its childs to console
# and also duplicate stdout and stderr to fd 3
exec 0<> $CONSOLE 1>&0 2>&0 1>&3 2>&3
and then renaming /etc/boot (to, say, boot.wrapped)
and calling it from a wrapper script (which will
reside in /etc/boot),
Now, the NEW boot script needs a way to record
everything while still doing what it does, here we
can use the command "tee" command. tee takes an input
(such as stdout or stderr) and directs it to TWO output
streams (a named file, and stdout)
the NEW /etc/boot (the wrapper script) does this--
it calls the old /etc/boot (now boot.wrapped) in
a subshell. The subshell has additional output
appearing on fd3, which is redirected to standard
input (fd0) in the wrapper's process space, and
piped into tee.
As it's name implies, tee is a pipe fitting, which
takes the standard input stream, and creates two output
streams...one being standard output, and the other
a named file.
touch /var/boot.console #create if not present
( boot.wrapped ) 3>&0 | tee -a /var/boot.console
Or if you want a brand new /var/boot.console each
time you boot up, then:
#
# call old /etc/boot, and duplicate it's fd3
# output to fd1, and feed into tee
#
((/var/boot.wrapped) | 1<&3 | tee /var/log/boot.console
WARNING... THE ABOVE CODE IS ***UNTESTED***
I'm speaking here from general principles. I
HAVE NOT TESTED this as a boot-up procedure on
my own machine -- i don't have the equipment
available at the moment to test this. USE AT
YOUR OWN RISK! But hopefully, this will give
you some ideas about what you can do.
At that point, all messages sent to stdout and stderr are lost
unless they are explicitly logged to the system log. dmesg contains
messages from the kernel -- not from the boot time scripts. As I
hinted in the "2nd" paragraph, below -- I want something that allows
me to "review" console "stdout" and "stderr" just like the boot-time
copy of dmesg, "/var/log/boot.msg" does for syslog messages.
M. Todd Smith wrote:
Have you tried looking through /var/log/messages?
There are various logging mechanisms used by various startup items.
Perhaps you can narrow the gamut a little and tell us what is failing?
---
If I could see all of the messages, I'd work on correcting
them myself. :-) Seriously -- all I see are occasional "error type"
messages..."file not found", or "module not loaded", or "script failed"
-- but none of that information is recorded in the system log as they
are messages from user-level programs that are run as scripts when
the system is being brought up. By "user-level", I mean the
"distro"'s boot and "rc" scripts -- programs that run in
"user-space" and simply echo messages to "stdout" & stderr (which is
set to /dev/console by the script called 'boot'). The opposite,
in this case, would be "kernel-level" processes that can only emit
output through kernel mechanisms like "printk".
While I want to look at all the output -- so I can see what is
happening at boot in more detail, I suppose I am a bit surprised that
errors during the boot-up scripts are not logged to syslog. While at
the end of the boot process, what services "failed" is echoed to the
console, even that summary information isn't saved in a (log)
file somewhere that I know of -- but I'd think that any error during
bootup -- from unexpected "files not found" to "can't load module"
errors should be logged.
I suppose if you want to look at it as a specific problem,
then my problem would be that I cannot read and review console
messages that occur during boot because they scroll off the screen
too quickly and (*most importantly*) such console output is not
saved in any file. Thus it is difficult to know what messages
indicate problems, and which are just ignorable (some "not found"
and "can't load module" messages, for example).
Thanks!
Linda
from base message(question):
"1st":
Specifically, on virtually every system, at times, messages just wiz
by on a bootup (especially after upgrades). Problem is that these
init-boot-script error messages are not saved anywhere. They are
^^^^^^^^^^^^
echoed to the console with error messages occasionally spitting out
interspersed with other startup messages, but its hard to track
everything down when the messages flit by so fast.
"2nd":
It'd be nice if "boot" could log all console output to a temp file
that would be copied into /var/log like boot.msg, on each system
^^^^^^
startup. I'd expect startup logging to stop as soon as login is
spawned to allow user login -- hopefully steering around any
user-privacy issues.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
