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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org