BootLogd

Revision 21 as of 2005-04-27 06:19:25

Clear message

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).
  • Currently, output between the kernel starting init and when bootlogd is started is lost. Move startup of bootlogd to as early as possible (possibly even to initramfs). Modify bootlogd to store output in ring buffer, and do not write to file
  • Use bootlogd; enabling it should be as simple as changing /etc/default/bootlogd. The udev problem should be fixed, any other bugs that come up can be fixed. Something for USplash can be hacked together (perhaps still capturing init script output via lsb-init functions) when necessary. The bootlogd author does not recommend using the daemon. Pros: quick and easy. Cons: inflexible, fragile.

  • Or, create a custom solution. Possibilities include:
    • log to /dev/log (syslog). For init scripts, either the lsb-init functions can handle std{err,out}, or rcS can be modified to redirect those when running init scripts.

    • prior to syslog being available, have a daemon started from init that logs all console output into a ring buffer, and then spits it all out once the network becomes available, or disk becomes writable (to /dev/log). Console logging can either just scrape the kernel's ring buffer (ie, klogd), and/or force init to log its childrens output (a patch from Red Hat is available for this).

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. Do we settle for bootlogd, or do we create something custom? Suse and Redhat both have patches floating around to modify init to log console to different places.

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.

    • 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.

    • 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.