Making Sense of startup

Some tips for figuring out what all the startup messages flying by your screen actually mean.

Many modern operating systems are happy to display a "please wait"
splash screen while booting--not so with Linux. Unlike other operating
systems, Linux is incredibly chatty while it boots, and I'm often asked
by new users to explain all the messages that appear during startup.
There's a raft of what appears to be random messages, followed by a
collection
of more ordered messages that appear as each of the operating system
services start. If the install/boot went well, these ordered messages
are accompanied by a brightly coloured (usually green) OK or DONE.
If something goes wrong, the messages usually display FAILED in red.
Unfortunately, both the random and the ordered messages disappear off
the screen quickly, usually well before a new user has had a chance to
read them.

It is possible to view the initial, random messages using the
dmesg command. A quick read of the dmesg manpage states
that dmesg is a utility that can "print or control the kernel
ring buffer". Among other things, the kernel ring buffer is the place
where boot messages are logged. The following command line displays
the ring buffer's current contents; notice the piping to less,
which displays the messages one screen at a time:

dmesg | less

By piping the dmesg command through grep, it is possible to
extract some specific data. For instance, use this command line to learn
about your system's USB setup (note the -i argument to grep,
which instructs the utility to ignore case, allowing USB as well as
usb to match):

As part of the Linux boot, the init process executes and the
operating system enters one of a fixed number of runlevels. The list of
runlevels are described at the start of the following configuration
file,
which is used by the init process:

/etc/inittab

Typically, as a result of a fresh install, your computer is configured
to boot into one of two runlevels, either runlevel 3 or runlevel 5.
The former starts Linux in full multiuser mode, presenting a text-based
login screen after a successful boot. The latter also starts Linux
in full multiuser mode, but a graphical, X11-based login screen
is presented. Which option you choose is a personal preference, and your
Linux installation program typically lets you choose either a text-based or
graphical login to use as the default. The /etc/inittab file
indicates on the id line which runlevel currently is the default on
your system. As I tend to boot to a text-based login on all my systems,
my id line within /etc/inittab looks like this:

id:3:initdefault:

If I change the 3 to a 5 and reboot, the graphical, X11-based login
screen appears. In order to edit the /etc/inittab file, superuser
privilege is required, so remember to log in as root when
editing this file.

The purpose of the various runlevels is to arrange for a specific
set of services to be started or stopped under certain circumstances.
Runlevels exist to reboot and halt the system, in addition to starting
services at boot-time. It is these services that relate to the more
ordered OK messages displayed at boot-time, as mentioned at the start
of this article.

A series of system service scripts exist in the /etc/init.d/ directory.
Another collection of subdirectories located under the /etc/rc.d/
directory corresponds to each of the runlevels.
Symbolic links within these subdirectories point to the service scripts.
By adding/removing symbolic links from the appropriate subdirectory, it
is possible to adjust which service scripts execute when Linux enters a
specified runlevel. However, doing so manually is often too much work.
In my view, it is much better to rely on a semi-automated tool, such as
chkconfig, to do the bulk of this work for you.

The chkconfig utility allows you to update and query the runlevel
information for your system services. Rather than fiddling with
symbolic
links, directory entries and service scripts, chkconfig does the
fiddling for you. Scripts are added or removed from the appropriate
rc subdirectory as needs be, allowing startup services to be controlled
more easily.

chkconfig typically resides in the /sbin/ directory, so be
sure to issue the following commands as root. To review the entire
list of startup services, sorted alphabetically, use this command line:

chkconfig --list | sort | less

A listing of the services appears, each accompanied by an indication
as to whether the service is enabled (on) when a particular runlevel is
activated or disabled (off). As always, the output is piped to less
to stop it scrolling off the screen. It often is useful to determine
which of these services are enabled. To do this, filter the output
through grep, as follows:

chkconfig --list | sort | grep ':on' | less

In addition to listing the current state of each of the startup
services,
ckconfig also can switch services on and off, with any changes taking
effect after the next boot. This means that if a service is enabled and
then is switched off with chkconfig, it remains running until the
system reboots. To switch the service off immediately, simply execute
the
service script (as root), passing the word stop as a command-line
parameter. For example, to arrange for the ISDN service to no
longer start at boot-time, issue this command:

chkconfig isdn off

his line ensures that the ISDN service is disabled at the next reboot.
To turn off the ISDN service without rebooting, use this command:

/etc/init.d/isdn stop

If you haven't switched off the ISDN service with
chkconfig, it will restart as part of the next reboot, even though
you stopped it by executing the service script. So, to immediately and
permanently stop the ISDN service, issue the above commands together:

chkconfig isdn off && /etc/init.d/isdn stop

To control which startup services are enabled at boot-time, work through
the list of services identified by chkconfig, switching on those you
want enabled and switching off those to be disabled. This is easy to do
when using chkconfig, assuming you know what each of the startup
services do.
If you are unsure, two techniques can help you to learn. The
first is straightforward: see if a manpage exists for the
service in question. For example, to display the manpage associated with
the crond service, issue this command line:

man crond

Assuming the manpage exists, it should provide plenty of information
about what the service does. You then can decide
if you want the service to start at boot-time and then use
chkconfig to enable or disable the service as need be. If no
manpage is available (there isn't for the ISDN service on my Red Hat 9
system), a message similar to this appears:

No manual entry for isdn

To determine what the ISDN service does, the second technique is to take
a look at the actual startup script stored in the /etc/init.d/ directory
using less. For example:

less /etc/init.d/isdn

Although the displayed script may look a little strange, concentrate
on the comment lines--they start with #--near the top of the script.
There should be a line labeled description to provide a clue
as to what the script does. For the ISDN service, the clue couldn't be
more clear:

# description: start and stop ISDN services

By working through the set of startup service scripts in an ordered way,
it is possible to configure services to suit your requirements.
In doing so, you learn what it is Linux is doing during the boot
process. Although GUI-based versions of chkconfig exist and
often are convenient to use, they assume the administrator is located
physically in front of the computer being managed. When accessing
a system for essential maintenance over a slow dial-up or remote network
connection, the command line based chkconfig is the only way to
go.

For more information on chkconfig, be sure to read its manpage.
To learn more about the boot process, start with the init manpage.

Paul Barry (paul.barry@itcarlow.ie) lectures at the
Institute of Technology,
Carlow, in Ireland. He is the author
of Programming the Network with Perl (Wiley 2002). His new book,
co-authored with Dr. Michael Moorhouse (of Erasmus MC, The Netherlands),
is titled Bioinformatics, Biocomputing and Perl (Wiley 2004).

I'd like to point out that you can see the non-random boot messages (with a green OK or a red Failed) by running/etc/init.d/xxxx start
where xxxx is the name of the service that failed. AFAIK these messages are not stored in any log file, so this is the best way to see them again...

A Linux box rarely needs to be rebooted for a change to take effect. Changes to some configuration files take effect as soon as the updated config file is saved by your editor, e.g., /etc/resolv.conf. For others you must inform the relevant service (daemon) of the change, usually by running the service's startup script with a reload or restart option (see service command on RedHat, maybe others too. Basically it supplies the path to the startup script for you.), or send a signal (HUP is common) to the daemon with the kill command. Some services have their own program for this purpose, e.g., ndc or rndc in BIND. Find out the difference between restart and reload options for each service you use. Some times they are identical, but not always. If you do reload on named the cache is preserved. If you do restart the cache is lost.

In the case cited above, changing the default run level in /etc/inittab, you tell init that it's config file has changed by running: init q or telinit q. If you have made a lot of changes it may be desirable to change to run level 1 (single user mode) and back to the desired run level, usually 3 or 5. Just do: init 1 wait for services to stop, then do: init 3 or init 5.

When must you reboot? After upgrading the kernel, after a kernel panic or hang, when doing anything that requires the power to be removed, BIOS setting changes, or testing changes to the startup or shutdown process to verify that they work correctly. There may be some other obscure situations requiring a reboot but I have not exprienced any others in 10+ years of using Linux.

If you can keep the power on, startup rarely happens. I have a Linux NFS server that has been up for 414 days as of today. Others have had them up even longer.

The "make a change and reboot" mindset comes from outside of the Unix/Linux world.

Thanks for the comment. I agree with what you say. However, the article was aimed at non-Linux users and newbies. The vast majorty of them come from "the other side" and I went with the familiar rather than go into the whole "there's no need to reboot" explanation. I was trying to keep things as simple as possible for an article of this type. Your point is well made and taken. Thanks again. --Paul.

In my experience, chkconfig is a tool on Redhat-based distros only; I have not encountered it on Slackware or Debian-based distros. It would have been nice of the author (or editors) to note this during this otherwise useful article.

For those interested, on Debian-based machines, the script update-rc.d performs much (but not all) of the functionality of chkconfig.