BootLogd

Differences between revisions 19 and 20
Revision 19 as of 2005-04-27 06:02:28
Size: 5285
Editor: intern146
Comment:
Revision 20 as of 2005-04-27 06:11:14
Size: 5585
Editor: intern146
Comment:
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
["USplash"] requirements need to be taken into consideration. ["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.
Line 58: Line 58:
The bootlogd author considers bootlogd experimental, and not suitable for end users.

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

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

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