En route to multi-user

Anyone too comfortable with the idea of run states on Unix systems might not be ready to hear this, but the process of going from a cold piece of hardware to multi-user mode has taken a couple very sharp turns in the last six years or so. Maybe you just aren't in the habit of looking under the hood and questioning how your system gets to the point of prompting you to log in, but that process has been going through some major upheavals. The idea of start scripts strategically waiting in rc#.d directories to be kicked into service is fading fast. If that's all you've seen, you haven't been jumping from one distribution to the other or maybe you've just spent your Unix time on Solaris or RedHat. Compare what you'll find on one of those servers with what you'll find on Fedora 17 or Ubuntu and you'll quickly see what I mean.

The traditional boot process involves the default run state being yanked from the /etc/inittab file.

id:5:initdefault:    <== Linux
is:3:initdefault:    <== Solaris

For Linux, the default run state is usually 5 and for Solaris 3.

This the state in which users can all log in and the desktop is available to anyone who can sit at the console or otherwise have the console come to them (via console server, remote desktop tool or what have you). Given the default run state, the init process can then go into the proper start-up directory, such as /etc/init.d/rc5.d, and begin the process of shutting down (i.e.,running K* scripts) and then starting up (running S* scripts) services in sequential order to ensure that all services that ought to be running in the default state are properly kicked into being.

But that's only one of the possible scenarios that you'll find on Linux systems today (and please don't tell my husband that I started a paragraph with the word "But"). Once revolutionary, then a millstone around the neck of Linux systems, this way of booting was straightforward, but not without some serious problems.

Your Fedora 17 system is likely to have nearly nothing in its /etc/init.d/rc5.d directory. Because nothing needs to be available in run state 5? Of course not! It's because there are newer and better ways to get from cold hardware to multi-user. Why did anyone want to change such a nice, easy to understand model of booting as we've come to know in the System V init process? Well, for one reason, sequentially starting up processes can be slow -- leading to a slow boot. If each process needs to get nudged into reading its configuration file, opening ports as needed and becoming fully functional before the next one can be woken up, we have something of a task queue. This process reminds me of the years in which I had three junior to high school daughters all wanting to take their morning showers before boarding their school busses (and, yes, this family of five was trying to make it with one shower!). Replace this model with a system that allows independent services -- those not dependent on other services -- to start asynchronously and you end up with a much faster boot process.

For another, the init model just starts services and then washes its hands of them. It doesn't do anything to make sure they continue running. It leaves it to independent monitoring and logging tools to get someone's attention when something goes wrong.

In walked Upstart ...

Upstart is an event-based replacement for the traditional init process. Introduced in 2006, Upstart operates asynchronously. Like that word? It means that processes don't have to wait on other processes before they can start. But Upstart is more than that. It also supervises services while the system is up and running. No more "put them on the bus and forget about them". Instead, it helps to ensure that the needed processes continue running. And boot time is much faster.

Upstart was designed to be backward compatible with the System V way of booting. So your traditional /etc/init.d/rc5.d methods don't have to disappear right away. RedHat has included Upstart in their Red Hat Enterprise Linux 6 release. If you are running RedHat 6 and you notice scripts have disappeared from /etc/init.d/rc5.d, that's why.

Upstart made some important inroads in the Linux world, but then something happened. Another method of going from cold hardware to multi-user mode began to displace it as "le choix du style" -- something called systemd.

In walked systemd ...

Systemd is another replacement for the System V init process. It is a system and service manager for Linux that is compatible with System V and LSB (Linux Standard Base) init scripts. It provides aggressive parallelization -- meaning that services can start even faster. It also supports snapshotting and restoration of the system state, maintains mount and automount points and impements an elaborate transactional dependency-based service scheme. It can, if needed, completely replace the old System V init scheme or work alongside it.

So, where is your system?

In the old days (say, a few years ago), you were probably setting up scripts in your /etc/init.d/rc5.d directory when you added services to your servers. You would add a script or two -- or maybe your install process would do that for you. Maybe a K11mysvc script was added to /etc/init.d/rc1.d to stop a service and a S88mysvc script was dropped into /etc/rc5.d to start it.

Today, how your system goes from cold hardware to multi-user depends on which flavor of init your system happens to be running. We'll take a deeper dip into these changes next week.

This article is published as part of the IDG Contributor Network. Want to Join?

Computerworld's IT Salary Survey 2017 results
Shop Tech Products at Amazon