BootLogd

Differences between revisions 27 and 28
Revision 27 as of 2005-04-27 12:14:09
Size: 6378
Editor: intern146
Comment: looks sane; one of the authors, if ready to make EditedSpecification, do so.
Revision 28 as of 2005-04-28 01:15:53
Size: 6398
Editor: intern146
Comment:
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
  * Status: BreezyGoal, UduBof, DistroSpecification, DraftSpecification[[BR]]   * Status: BreezyGoal, UduBof, DistroSpecification, DraftSpecification, ColinCharlesQueue[[BR]]
Line 42: Line 42:
    * Log to syslog instead of writing directly to file. This allows for more flexibilty, as we can suddenly log all console output remotely.     * Log to syslog instead of writing directly to file. This allows for more flexibility, as we can suddenly log all console output remotely.
Line 44: Line 44:
        * With appropriate bootloader commands and a working ethernet network, should allow submitting straight to the HardwareDatabase even if the root filesystem can't be brought up.         * With appropriate bootloader commands and a working Ethernet network, should allow submitting straight to the HardwareDatabase even if the root filesystem can't be brought up.

UbuntuDevel/BootLogd

Status

Introduction

Preserve output from the system initialization process.

Rationale

A lot of useful information is discarded, especially due to early gdm startup, and later ["USplash"]. This becomes an even larger problem as things are moved earlier and earlier into the boot process.

Scope and Use Cases

  • Debugging user problems early in the boot process (init script related). Logging everything to a file will go a long way towards tracing problems.
  • ["USplash"] wants a way to grab status information and output from init scripts, and displaying a subset of it. As well, init script output should be directed to /dev/null, or some other tty, so that the user doesn't see it.

  • Enable remote logging of problems on servers, for cases where the disk is not writable.

Implementation Plan

  • Enable bootlogd immediately; this simply requires changing '/etc/default/bootlogd'. Fix immediate bugs (at least on Debian and Hoary, it seems to log correctly).
  • Modify bootlogd to create a socket/pipe/pty device in /dev (ie, /dev/bootlogd). Anything written to this device will get written to the log file (/var/log/boot).
  • Modify init scripts to (if VERBOSE=no in /etc/default/rcS) redirect output to /dev/bootlogd instead of /dev/null. This ensures that the user only sees "pretty" output on console, but verbose output ends up in /var/log/boot.
  • ["USplash"] can either hook into bootlogd's nonverbose output (requiring modifications to bootlogd), or can hook into init scripts
  • Possible enhancements:
    • Move initramfs startup to even earlier in the boot process (perhaps from initrd or initramfs). Currently, bootlogd will store output in a ring buffer, and dump to file once the file is writable. Ensure that this ring buffer is large enough for the extra output added by bootlogd starting earlier. As things are moved into initramfs (ie, hotplug), this becomes more important.
    • Log to syslog instead of writing directly to file. This allows for more flexibility, as we can suddenly log all console output remotely.
      • Support logging via 'netcat' straight to another IP:port on a different machine.

        • With appropriate bootloader commands and a working Ethernet network, should allow submitting straight to the HardwareDatabase even if the root filesystem can't be brought up.

Data Preservation and Migration

  • N/A

Packages Affected

  • sysvinit

  • lsb-init

  • initscripts

User Interface Requirements

["USplash"] requirements need to be taken into consideration; if it is using the non-verbose output from init scripts, this needs to be made available in a simple fashion. Non-USplash users should not see verbose output on their console, but it should be logged to a file.

Outstanding Issues

The bootlogd author considers bootlogd experimental, and not suitable for end users. We should find out the author's exact concerns, and check the relevancy. ["USplash"] requirements, once it has a clear implementation path, may require further bootlogd or init changes, or vice-versa.

UDU BOF Agenda

  • What needs to be done in order to enable bootlogd?
  • Enable it and start fixing the bugs
  • How early should it be enabled? One of the suggestions ([http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272428 #272428]) included starting bootlogd from initrd, so that everything gets logged.

UDU Pre-Work

  • Bootlogd is started (in debian) from S05 (after udev, mountvirtfs, and mdadm), and logs to /var/log/boot. The (sysvinit) author considers it broken/experimental, and has disabled it by default.

  • Known problems include:
    • [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205724 #205724]: Since it runs before fsck, it logs all spinner changes. This causes huge logfiles, and slows down fsck considerably since it fsyncs after every line/write. Joeyh proposed only writing upon newlines...

    • [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237056 #237056]: udev was not providing /dev/ttyzf, which bootlogd needs. This appears to no longer be the case; at least w/debian's udev_056-2 + 2.6.11, as well a hoary's udev (w/ 2.6.10), /dev/ttyzf is created.

    • [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213028 #213028]: bootlogd needs to not run while in single user mode, otherwise things like passwords, fsck, and lots of unnecessary stuff end up getting logged to a world-writable log file.

    • direct logging of console requires a) figuring out what the console actually is (parsing kernel arg console=,
      • etc; pre-2.4, there was an ioctl to get w/ this, TIOCGDEV), and b) logging terminal control characters.
  • Suggestions by the author:
    • Add more support in kernel for bootlogd; author didn't expand upon that.

      • Providing a 'tee' ioctl() rather than a 'redirection' would be better and suit our needs better.
    • Provide wrapper for starting init scripts, that logs all output to /dev/bootlogd. Bootlogd listens on this socket, stores logging info in ring buffer, and dumps to /var once it's writable.

    Other possibilities:
    • When starting init scripts from /etc/init.d/rc{,S}, log all output to socket and console. Bootlogd then reads logs from socket instead of /dev/console. Or, skip bootlogd stuff and write to /dev/log once sysklogd has been started, so that syslog.conf can control logging.

      • Can be done by replacing '/dev/null' with $MESSAGE_BUCKET

        • Figure out Pipe/Rediction/Tee syntax for this.
    • Start bootlogd from initrd; store logs in ring buffer until /var/log is writable, at which point dump early logs to disk, fsync, and begin normal logging.

UbuntuDownUnder/BOFs/BootLogd (last edited 2010-03-31 07:46:27 by pool-71-173-140-218)