One of the biggest problems I ran into with Gentoo was the fact that there's no logging for the scripts that are run at boot time (the /etc/init.d scripts linked in either the boot or default runlevels). This makes debugging very hard when error messages scroll by in a hurry. I understand it may not be possible to use the sys logger as it may not be initialized yet at boot time, but some sort of logging that can be analyzed later should be in place (such as teeing the output to a file). Reproducible: Always Steps to Reproduce: 1. 2. 3.
when the scripts error or show a warning they log ...
where do they log??
syslog, of course. grep -r rc-scripts /var/log/ Only when ewarn or eerror is used. However, stdout and stderr is NOT logged.
Well, they should. I think this is a valid enhancement request. Usually the important information goes to stdout & stderr
Its going to slow things a tad. I will rather add it with a /etc/conf.d/rc toggle, and maybe on that you can pass as kernel param.
I don't understand ... what's going to be slower? The whole boot process? Does it matter if it's 5 sec. slower? I would not care, a Linux machine is not something you have to reboot every 5 min. after the initial setup phase. However, an option would be OK too, I suppose it could be used in the beginning to get things going and then it can be tunred off. It would be really nice though to have a summary of the errors at the end of the boot process, to at least know whether everything went OK. A simple "No boot errors" or "Errors detected, see the log files in /var/log/rc-scripts..."
Hi, I also have the problem of not be able to see all of the output of the init scripts :(. I think it could be solved by: 1) Make the "pause" key work 2) Provide an option at boot time so that the system asks if he should start up script X for every script (I thought SuSE did it like this, Windows does (did?) this when booting in "Safe mode") 3) Make a logging facility 4) Make shift + PgUp work But this view is an end user point of view :(. But I would say: just pick the fastest solution ;)...
If you can tell me how to make 1),3) and 4) work, as well as ctrl-c, I will appreciate.
Created attachment 20477 [details, diff] This echos all output to /dev/kmsg (kernel 2.6.x only). This will echo all output to /dev/kmsg if it is writable (only 2.6.x kernels). It patches /sbin/functions.sh
Created attachment 20478 [details] A sample dmesg output with new the functions.sh
You'll need to add this to /etc/conf.d/rc: # Set to "yes" to log all init.d/ messages to /dev/kmsg RC_USE_KMSG="yes"
Created attachment 20771 [details, diff] Patch for /sbin/functions.sh This patch actually works. I had to change the * to ^ due to bash weirdness.
Two issues: 1) We do not want to do this if $EBUILD is set. A better way might be to check for $myservice, which means we will be in a rc-script. 2) I do not think we want colors in there. Alternatively, we might want to prepend $myservice to the messages, and maybe pipe all stderr to kmsg as well ... Other than this it looks like a workable start. Comments?
i like the idea of checking $myservice because ebuilds arent the only thing that uses functions.sh for einfo/ebegin/etc...
Created attachment 20834 [details, diff] /sbin/functions.sh patch for /dev/kmsg Here's another patch: 1. Checks for $EBUILD 2. Removes all color to /dev/kmsg output. Still need to do: 1. Use $myservice instead of $BUILD; this doesn't appear to be a simple thing. 2. Send stderr to /dev/kmsg.
On another note in /sbin/functions.sh, I really dislike this : # Should we use color? RC_NOCOLOR="no" First it is a double-negative and is confusing. It should just be RC_COLOR, which everyone would understand. I could put together a patch if you think it would be accepted.
Is this the correct method to determine if $myservice is an init.d/ script? echo_kmsg() { if [ -n "${myservice}" ] && [ -e "/etc/init.d/${myservice}" ] && [ "${RC_USE_KMSG}" = "yes" ] && [ -w /dev/kmsg ] then echo ${*} >> /dev/kmsg fi }
Created attachment 24776 [details, diff] /sbin/functions.sh patch to send output to /dev/kmsg This removes the ENDCOL since it messes up the dmesg output. Also ebegin output will not have a newline.
Soo... this is getting rather old. Any plans to accept this?
nope i have a small patch to do logging via blogd like SuSE does it
Why use blogd? Everyone running 2.6.x has /dev/kmesg. Not that I really care... this is so old it is not even funny anymore.
- not everyone uses 2.6 - not everyone makes /dev/kmsg available - blogd is transparent and requires no modifications to baselayout except to start and stop it - the current solution provided here does not catch the output generated by applications (the rc system said 'error' but that's useless unless you see the error message generated by the app itself)
blogd has been integrated into stable baselayout
