Prev: [PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.
Next: [PATCH tip/core/urgent 06/10] sched: Fix an RCU warning in print_task()
From: Marco Stornelli on 2 May 2010 06:10 01/05/2010 20:48, Samo Pogacnik wrote: > Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a): >>> while i was searching for effective logging of complete console output >>> produced by the kernel and user phase of the boot process, it turned out >>> that only kernel messages imho get systematically cached and stored into >>> log files (if needed). All userspace processes are on their own to use >>> syslog, which is fine, but there are also many console messages >>> reporting the boot status via init scripts, .... I came across the >>> bootlogd daemo, which handles the job of redirecting console output into >>> a log file, but i find it problematic to use especialy, when using >>> initial ram disk image. >> >> So you want to patch the kernel because you can't work out how to do this >> in userspace ? The distributions seem to have no problem doing this in >> user space that I can see. It doesn't seem to be a hard user space >> problem, and there are a ton of things you want to do with this sort of >> stuff (like network logging) that you can't do in kernel space. > > The distros have no problem logging complete console output into log > files or over the network, because they simply do not do it at least for > the initrd part of the boot process (i'd be glad, if i'm wrong). Mmm...It's an interesting problem. I see in my distro (openSuse) a script called boot.klog that it seems to perform that (even initrd part). In the file boot.msg I can see the initial prints of the kernel and user space scripts. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Samo Pogacnik on 2 May 2010 09:40 Dne 02.05.2010 (ned) ob 11:58 +0200 je Marco Stornelli zapisal(a): > 01/05/2010 20:48, Samo Pogacnik wrote: > > Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a): > >>> while i was searching for effective logging of complete console output > >>> produced by the kernel and user phase of the boot process, it turned out > >>> that only kernel messages imho get systematically cached and stored into > >>> log files (if needed). All userspace processes are on their own to use > >>> syslog, which is fine, but there are also many console messages > >>> reporting the boot status via init scripts, .... I came across the > >>> bootlogd daemo, which handles the job of redirecting console output into > >>> a log file, but i find it problematic to use especialy, when using > >>> initial ram disk image. > >> > >> So you want to patch the kernel because you can't work out how to do this > >> in userspace ? The distributions seem to have no problem doing this in > >> user space that I can see. It doesn't seem to be a hard user space > >> problem, and there are a ton of things you want to do with this sort of > >> stuff (like network logging) that you can't do in kernel space. > > > > The distros have no problem logging complete console output into log > > files or over the network, because they simply do not do it at least for > > the initrd part of the boot process (i'd be glad, if i'm wrong). > > Mmm...It's an interesting problem. I see in my distro (openSuse) a > script called boot.klog that it seems to perform that (even initrd > part). In the file boot.msg I can see the initial prints of the kernel > and user space scripts. > Thanks for the info. Is this boot.klog script from the initrd image or from the real rootfs? As you can see, i am still suspicious about the initrd part user console messages:) Samo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marco Stornelli on 3 May 2010 13:10
Il 02/05/2010 15:29, Samo Pogacnik ha scritto: > Dne 02.05.2010 (ned) ob 11:58 +0200 je Marco Stornelli zapisal(a): >> 01/05/2010 20:48, Samo Pogacnik wrote: >> >> Mmm...It's an interesting problem. I see in my distro (openSuse) a >> script called boot.klog that it seems to perform that (even initrd >> part). In the file boot.msg I can see the initial prints of the kernel >> and user space scripts. >> > Thanks for the info. > Is this boot.klog script from the initrd image or from the real rootfs? > As you can see, i am still suspicious about the initrd part user console > messages:) > > Samo > > In the initrd there's the script blogd.sh: if test -z "$fboot" -a -z "$quiet" -a -z "$REDIRECT" ; then REDIRECT=$(showconsole 2>/dev/null) if test -n "$REDIRECT" ; then if test "$devpts" != "yes" ; then mount -t devpts devpts /dev/pts devpts=yes fi > /dev/shm/initrd.msg ln -sf /dev/shm/initrd.msg /var/log/boot.msg mkdir -p /var/run /sbin/blogd $REDIRECT fi fi And in the rootfs the boot.klog script: # Read all kernel messages generated until now and put them in one file. test -s /var/log/boot.msg && mv -f /var/log/boot.msg /var/log/boot.omsg echo Creating /var/log/boot.msg if test -x /sbin/klogd ; then # klogd syncs out the file /sbin/klogd -s -o -n -f /var/log/boot.msg test -s /var/log/boot.msg rc_status -v1 -r elif test -x /bin/dmesg ; then /bin/dmesg > /var/log/boot.msg /bin/sync test -s /var/log/boot.msg rc_status -v1 -r fi if test -e /dev/shm/initrd.msg ; then cat /dev/shm/initrd.msg >> /var/log/boot.msg rm -f /dev/shm/initrd.msg fi [ --- cut here --- ] Regards, Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |