suggestion for default arch logging behavior

djg1971 · 2010-01-27 16:18:43

Okay let me throw this out there and see what comes back...

Every Linux distribution I have used (apart from arch) has a boot log file enabled by default, or provides a simple Yes/No flag to turn the feature on.

Arch does not. Moreover, I have searched the forums and posted a question or two myself about the topic. No one seems to know the answer, and a lot of responses seem to indicate that, amongst the arch community, the possibility of a boot log file is treated like: a) something that no one in their right mind would want, or b) something that maybe, might be useful, but that no one can figure out how to implement.

What is this? What is going on? Arch has a bootlogd binary in /sbin/. Presumably there is no reason why it won't actually work, but no one seems to know where to put the call to the binary, or why they would put it there.

This seems like an easy-to-add feature that a developer or moderator (anyone who really knows the system layout well) could make the default for future installs. It just makes a text file that is a) not large, and b) can be very useful at times.

So how about it? Why not make this part of the default arch logging set up? (and of course explain what you did that worked.)

drcouzelis · 2010-01-27 17:13:25

I'm sorry, I don't have much to add but, would that kind of logging allow me to see everything my computer does, from the time BIOS finishes until the login screen appears?

Because I have been looking for that kind of log file on my computer.

djg1971 · 2010-01-27 17:36:38

drcouzelis:

Traditionally, the "boot log" is a text file record of everything echoed to the screen during the boot process. I.e. after logging into your system, at any time you can type "more /var/log/boot" (or wherever the log file was written -- /var/log/. is common) and see, eg. "Starting something you really want to work..............................[FAILED]" and so on. It is useful when things fail but the message(s) go by so fast that you can't read them. And no, not everything you might want to know is available via dmesg.

One way to accomplish said logging is via /sbin/bootlogd. Arch systems seem to have this binary, but I tried placing it in a few places inside the startup scripts and while I did no harm I did not get a useful boot log file.

Since any redhat, fedora, debian, ubuntu, etc. system easily provides this feature, I was thinking it might be nice for arch linux to do the same. Unfortunatlely, that seems to require some input from arch power users who have so far either been a) stumped themselves, b) unwilling to answer, or c) unwilling to comment on why they don't want to put this feature into arch.

So I thought I'd post it as a suggestion in this forum and see what came of it...

Xyne · 2010-01-27 18:41:57

For what it's worth, I think this would be useful at times, provided it could be enabled/disabled at will.

djg1971 · 2010-01-27 19:37:53

Xyne:

Since you took the time to reply to the post, do you know where to put the call "/sbin/bootlogd" such that this will work with an arch system? (albeit in hard-wired fashion)

For example, I tried inserting the statement in "/etc/rc.sysinit" after the "minilogd" is started, but this doesn't work (bootlogd starts, but can't latch on to the console or tty), so you get a /var/log/boot file of zero size. Presumably it needs to be called as early as possible, just not so early that it is impossible for it to work.

I guess the question might be: Where in the arch boot process does the output you see echoed to the screen actually get associated with a console device?

Xyne · 2010-01-27 19:51:54

I don't know. I have never fiddled with init scripts etc. If I had had any idea, I would have posted it.

tomk · 2010-01-27 19:52:38

Probably needs to go in early userspace i.e. the initramfs image.

If you can't figure it out, post a feature request for it anyway, with as much info as you have. This thread may be useful for discussion, but the devs probably won't see it.

Also read the BUGS section of man bootlogd - Arch does have a "new-style /dev/console device (major 5, minor 1)".

djg1971 · 2010-01-27 21:12:35

tomk:

I did read the man page for bootlogd, however I found the "BUGS" section a little misleading, or at least confusing: With the attempt I mentioned in the earlier posting, the behavior is that *on boot* the log file generated is of zero size, however the process sticks around, and upon a subsequent reboot (at least if the call to bootlogd is removed), one finds that the *shutdown* information (or some of it at least) does end up in the log file.

So it is not clear to me whether (as the man page says) there is no standard way AND it isn't going to work for an arch system without more substantial tweaks, or whether it in fact is working, one just needs to place the call to bootlogd in exactly the right place, and I don't know where that is.

Anyway I'll post a request and try to make it as helpful as I can.

djg1971 · 2010-01-27 21:45:44

tomk:

I posted a request (though in the AUR request forum -- couldn't see where else to put it).

Hopefully someone will take an interest.

skanky · 2010-01-27 22:30:39

I think you're meant to add it as a feature request in the bugtracker. It's in the menu at the top, labelled "Bugs".

Edit: happy to be corrected if wrong.

Last edited by skanky (2010-01-27 22:31:38)

djg1971 · 2010-01-27 22:32:25

Yes, thanks, already done. Someome mentioned that as a reply to my post in the AUR request forum.

skanky · 2010-01-27 22:42:50

djg1971 wrote:

Yes, thanks, already done. Someome mentioned that as a reply to my post in the AUR request forum.

Ah okay. Sorry, should have checked there first.

djg1971 · 2010-01-28 16:12:19

If anyone is interested, this topic (i.e. getting bootlogd to work in arch systems, or achieving the equivalent functionality) is now in the queue as a bugtracker feature request.

It is not high priority, so I encourage anyone interested to experiment at planned reboots by inserting the statement "/sbin/bootlogd" into various init scripts at whatever seems like a promising location. After your machine has rebooted, check the default location for the log file (/var/log/boot) and see if you have:

a) no log file
b) zero-size log file
c) success

I usually get b. If you find c, please post the solution to this topic or email me individually that you've managed to figure it out.

tomk · 2010-01-28 16:53:08

Are you not going to try it in the init image?

lucke · 2010-01-28 17:04:30

I've tried it in the image and after minilogd, in both cases I get no log file at all.

djg1971 · 2010-01-28 17:22:55

tomk:

Sorry to disclose my ignorance, but I'm not sure how to do that.

What I have been doing though is trying to see in more detail how it is done on a debian system which I have access to. Here is what I've learned so far:

There are not that many references to bootlogd on the system, so it might be possible (for me) to track down what is going on:

root@wave32p:/etc# locate bootlogd
/etc/default/bootlogd
/etc/init.d/bootlogd
/etc/init.d/stop-bootlogd
/etc/init.d/stop-bootlogd-single
/sbin/bootlogd
/usr/share/man/man8/bootlogd.8.gz

1) "/etc/default/bootlogd" must be edited (trivially) such that a "No" becomes a "Yes" -- this seems like just a master switch.

2) the man files are exactly the same on the two systems, and the output of "/sbin/bootlogd -v" is the same on the two systems, however the size of the bootlogd binary itself is not the same on both systems (larger on debian64 system). not sure what to make of that, but it is not what I was hoping to see.

3) the script "/etc/init.d/bootlogd" runs with (eg.) a "start/stop" flag, the same as most "functions" under arch that have scripts associated with them.

4) it would seem that I have to grind my way through the above script if I'm going to make any progress. I'm doing that in my spare time at the moment, though it's a challenge since it's been a few years since I've written bash scripts on a regular basis. FYI, here is the /etc/init.d/bootlogd script verbatim (additional note: the option -r (below) is supported on the arch version of the bootlogd binary, but the -c option does not seem to be...interesting? Here is the man page entry for -c: "Attempt to write to the logfile even if it does not yet exist. Without this option, bootlogd will wait for the logfile to appear before attempting to write to it. This behavior prevents
bootlogd from creating logfiles under mount points."):

#! /bin/sh
### BEGIN INIT INFO
# Provides:          bootlogd
# Required-Start:    mountdevsubfs
# X-Start-Before:    hostname keymap keyboard-setup procps pcmcia hwclock hwclockfirst hdparm hibernate-clean
# Required-Stop:
# Default-Start:     S
# Default-Stop:
# Short-Description: Start or stop bootlogd.
# Description:       Starts or stops the bootlogd log program
#                    which logs boot messages.
### END INIT INFO

PATH=/sbin:/bin  # No remote fs at start
DAEMON=/sbin/bootlogd
[ -x "$DAEMON" ] || exit 0
NAME=bootlogd
DESC="boot logger"
BOOTLOGD_OPTS="-r -c"
[ -r /etc/default/bootlogd ] && . /etc/default/bootlogd
. /lib/init/vars.sh

. /lib/lsb/init-functions

# Because bootlogd is broken on some systems, we take the special measure
# of requiring it to be enabled by setting an environment variable.
case "$BOOTLOGD_ENABLE" in
  [Nn]*)
    exit 0
    ;;
esac

# Previously this script was symlinked as "stop-bootlogd" which, when run
# with the "start" argument, should stop bootlogd.  Now stop-bootlogd is
# a distinct script, but for backward compatibility this script continues
# to implement the old behavior.
SCRIPTNAME=${0##*/}
SCRIPTNAME=${SCRIPTNAME#[SK]??}
ACTION="$1"
case "$0" in
  *stop-bootlog*)
    [ "$ACTION" = start ] && ACTION=stop
    ;;
esac

case "$ACTION" in
  start)
      # PATH is set above
    log_daemon_msg "Starting $DESC" "$NAME"
    if [ -d /proc/1/. ]
    then
        umask 027
        start-stop-daemon --start --quiet --exec $DAEMON -- \
            $BOOTLOGD_OPTS
        ES=$?
    else
        $DAEMON $BOOTLOGD_OPTS
        ES=$?
    fi
    log_end_msg $ES
    ;;
  stop)
    PATH=/bin:/sbin:/usr/bin:/usr/sbin
    log_daemon_msg "Stopping $DESC" "$NAME"
    start-stop-daemon --oknodo --stop --quiet --exec $DAEMON
    ES=$?
    sleep 1
    log_end_msg $ES
    if [ -f /var/log/boot ] && [ -f /var/log/boot~ ]
    then
        [ "$VERBOSE" = no ] || log_action_begin_msg "Moving boot log file"
        # bootlogd writes to boot, making backup at boot~
        cd /var/log && {
            chgrp adm boot || :
            savelog -q -p -c 5 boot \
            && mv boot.0 boot \
            && mv boot~ boot.0
        }
        ES=$?
        [ "$VERBOSE" = no ] || log_action_end_msg $ES
    fi
    ;;
  restart|force-reload)
     /etc/init.d/bootlogd stop
     /etc/init.d/bootlogd start
    ;;
  status)
    status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
    ;;
  *)
    echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload|status}" >&2
    exit 3
    ;;
esac

:

djg1971 · 2010-01-28 17:46:43

for anyone interested, the following forum discussion (ubuntu & debian I think) may also be illuminating:

http://www.linuxquestions.org/questions … ng-746468/

tomk · 2010-01-28 21:30:36

I've put the init script in code tags for you - please do that in future with any similarly large chunks of code.

Arch Linux

#1 2010-01-27 16:18:43

suggestion for default arch logging behavior

#2 2010-01-27 17:13:25

Re: suggestion for default arch logging behavior

#3 2010-01-27 17:36:38

Re: suggestion for default arch logging behavior

#4 2010-01-27 18:41:57

Re: suggestion for default arch logging behavior

#5 2010-01-27 19:37:53

Re: suggestion for default arch logging behavior

#6 2010-01-27 19:51:54

Re: suggestion for default arch logging behavior

#7 2010-01-27 19:52:38

Re: suggestion for default arch logging behavior

#8 2010-01-27 21:12:35

Re: suggestion for default arch logging behavior

#9 2010-01-27 21:45:44

Re: suggestion for default arch logging behavior

#10 2010-01-27 22:30:39

Re: suggestion for default arch logging behavior

#11 2010-01-27 22:32:25

Re: suggestion for default arch logging behavior

#12 2010-01-27 22:42:50

Re: suggestion for default arch logging behavior

#13 2010-01-28 16:12:19

Re: suggestion for default arch logging behavior

#14 2010-01-28 16:53:08

Re: suggestion for default arch logging behavior

#15 2010-01-28 17:04:30

Re: suggestion for default arch logging behavior

#16 2010-01-28 17:22:55

Re: suggestion for default arch logging behavior

#17 2010-01-28 17:46:43

Re: suggestion for default arch logging behavior

#18 2010-01-28 21:30:36

Re: suggestion for default arch logging behavior

Board footer