BootLogd

Differences between revisions 36 and 37
Revision 36 as of 2005-12-25 23:03:19
Size: 6705
Editor: S0106001217cbd164
Comment: move out of main namespace
Revision 37 as of 2008-08-06 16:18:36
Size: 6715
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
  * Created: [[Date(2005-04-23T03:13:53Z)]] by MattZimmerman[[BR]]
  * Priority: LowPriority[[BR]]
  * People: AndresSalomonLead, HerbertXuSecond[[BR]]
  * Contributors: MattZimmerman[[BR]]
  * Interested: OliverGrawert, JeffBailey, PaulSladen [[BR]]
  * Status: BreezyGoal, UduBof, DistroSpecification, ApprovedSpecification[[BR]]
  * Branch: [[BR]]
  * Malone Bug: [[BR]]
  * Packages: [[BR]]
  * Depends: [[BR]]
  * Created: <<Date(2005-04-23T03:13:53Z)>> by MattZimmerman<<BR>>
  * Priority: LowPriority<<BR>>
  * People: AndresSalomonLead, HerbertXuSecond<<BR>>
  * Contributors: MattZimmerman<<BR>>
  * Interested: OliverGrawert, JeffBailey, PaulSladen <<BR>>
  * Status: BreezyGoal, UduBof, DistroSpecification, ApprovedSpecification<<BR>>
  * Branch: <<BR>>
  * Malone Bug: <<BR>>
  * Packages: <<BR>>
  * Depends: <<BR>>
Line 24: Line 24:
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. 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.
Line 29: Line 29:
  * ["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.   * [[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.
Line 37: Line 37:
  * ["USplash"] can either hook into bootlogd's nonverbose output (requiring modifications to bootlogd), or can hook into init scripts   * [[USplash]] can either hook into bootlogd's nonverbose output (requiring modifications to bootlogd), or can hook into init scripts
Line 58: Line 58:
["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. [[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 62: Line 62:
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. 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.
Line 68: Line 68:
 * 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.  * 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.
Line 75: Line 75:
   * [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.
   * [[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.
Line 80: Line 80:
       * There is a [http://dl.bytesex.org/patches/2.6.12-rc3-1/tiocgdev TIOCGDEV] patch for the Linux kernel. `bootlogd` already supports use of the IOCTL if it's defined by `glibc`, but `glibc` does not yet, thus the IOCTL command number will need to be (temporarily) hard-coded (ifdef) into `bootlogd` for it to work.        * There is a [[http://dl.bytesex.org/patches/2.6.12-rc3-1/tiocgdev|TIOCGDEV]] patch for the Linux kernel. `bootlogd` already supports use of the IOCTL if it's defined by `glibc`, but `glibc` does not yet, thus the IOCTL command number will need to be (temporarily) hard-coded (ifdef) into `bootlogd` for it to work.

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 bootlogd 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

  • initramfs-tools

  • linux-image-* (?)

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 (#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:
    • #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...

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

    • #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:
      1. figuring out what the console actually is, either by parsing kernel arg console=, or using the TIOCGDEV ioctl (not present in stock kernels as of 2.6.12)
        • There is a TIOCGDEV patch for the Linux kernel. bootlogd already supports use of the IOCTL if it's defined by glibc, but glibc does not yet, thus the IOCTL command number will need to be (temporarily) hard-coded (ifdef) into bootlogd for it to work.

        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.


CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/BootLogd (last edited 2010-03-31 07:46:27 by cityguy)