September 17, 2012, 10:57 AM — 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!).