Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/boot-message-logging

• Created: Date(2006-06-06T19:51:57Z) by ScottJamesRemnant

• Contributors: ScottJamesRemnant, JeffBailey, SimonLaw

• Packages affected:

Summary

This specification defines what messages will be available during boot, which will be logged and which will be shown by default.

Rationale

Currently much of the information about what goes on during the boot process is lost because there is no writable filesystem to dump it to, and too much information is normally displayed to the screen preventing problems from being found.

The log of what happens during boot is useful to both developers and systems administrators debugging problems with the system.

Use cases

• Benson is user who is not tech-savvy and is currently confused by the large number of messages during the boot sequence. He would be comforted by no messages and a simple indication that the machine has not hung.
• Karl is a systems administrator who would like to be able to watch servers boot and see which services are starting and which have failed to start.
• Duncan is a consultant who has been called in to determine why a client's server is not running correctly, the problem happens at boot and there are no useful log files for him to read.
• Dale is an Ubuntu developer and bug contact for a package that is failing at boot-time, he would like be able to ask for a verbose log file of the boot to quickly pin-point the problem.
• Greg is a member of the Ubuntu QA team who triages incoming bug reports before giving them to developers, a single verbose log file of the boot would be a great aid towards determining the cause of the problem.

Scope

This specification describes the different levels and methods of boot message logging that should be made available, however it does not specify the implementation as that will likely be handled by the ReplacementInit specification.

Design

The following levels of message output are defined, each includes all of the previous things if appropriate.

Quiet

This is the level of information that will be passed to usplash by default, and sent to /dev/console when usplash is normally running.

• Critical messages only. Any message printed explains why the boot process is being delayed or stopped immediately after the message.
• Progress of fsck is displayed.
• Boot activity is shown, either as a progress bar or throbber if appropriate. Whichever is displayed will be driven by activity from the init system, rather than idle time, so inactivity can be spotted.

  Loading kernel.....
  
  
  Ubuntu edgy (development branch) ubuntu tty1
  
  ubuntu login:

Failures

This is the level of information that will be sent to /dev/console on servers where usplash is not normally running.

• The names of services or scripts that failed during boot are printed, with a short error message if a useful one can be obtained.

  Loading kernel...
  
  apache2 failed: unable to bind to 192.168.1.1
  
  
  Ubuntu edgy (development branch) ubuntu tty
  
  ubuntu login:

Services

• "Service starting" messages will be shown on a single line, overwriting any previous starting message on that line.
• "Service failed" messages will be shown and the cursor moved down to the next line for future messages.

(example during boot, once boot has complete it looks the same as the Failures mode)

• Loading kernel...
  
  apache2 failed: unable to bind to 192.168.1.1
  Starting postgresql...

Verbose

This is the level of information that will be placed in /var/log/boot.

• Kernel messages.
• Names and arguments of scripts being run.

• Commands run within each script (sh -x), perhaps optional.

• Output of every service and script run.

• Early capture of syslog() calls by reading from /dev/log until syslogd is able to take over.

Implementation

While the actual implementation is largely dependant on the init system selected for edgy, it is possible to define the following:

• Scripts should output liberally to standard output and standard error without concerning themselves with policy such as the current "$VERBOSE" variable.

• Messages of particular importance would be logged using functions either similar to, or just using the LSB init functions.

• Standard output and error of init scripts would be redirected and not sent to /dev/console.

• Kernel messages would not be sent to /dev/console.

• A process (see Code, below) would need to read the kernel messages, syslog messages and messages from the init scripts.

• fsck should be run such that it's progress output is captured and sent to usplash

• The init system would output messages for services being started and stopped.

Code

Line-terminated messages from various sources will need to be read and stored in memory until a writable filesystem is available, at which point they will be written to /var/log/boot and subsequently appeneded to that file.

Messages should be timestamped and the origin noted.

For future expansion, this program could also write the messages to a designated network socket (on the kernel command-line, causing the network card to be configured in initramfs) providing piece-of-mind during remote reboots.

CategorySpec