How Linux "knows" what to start at boot time

When you boot up a Linux computer, you'll usually see the bootloader (after the BIOS has done its part of the booting process). The bootloader, usually Lilo or GRUB, is configured to load the kernel of the Linux into the memory of your computer. The kernel then leaves the bootloader behind and continues booting on its own, initializing hardware and making itself ready to start running init. And init is the process we're looking for: it is the first process run, and it spawns all other processes. But where does init look to know which processes to start? The short answer is: in /etc/rc*.d/ (usually). But that's not the full answer. To understand how it uses the files in those directories, we will first need to understand what runlevels are.

[b]Runlevels[/b]
A runlevel is the process state in which a system can reside. For example: runlevel 1 usually is the rescue mode, it boots the system starting as few processes as possible, providing the user with a root-access console, without networking functionality and without any GUI. On the other hand, runlevel 5 usually is the full-fledged graphical multi-user mode. There also are special runlevels that you shouldn't boot to, but that you could switch to after booting: for example, switching to runlevel 0 (zero) shuts down your computer (don't try this until you read the full tutorial) and switching to runlevel 6 will make your system reboot itself. Now for the full list of runlevels and their common configuration:

* 0: Shuts down the system (to be switched to after booting)
* 1: Boots the system to a rescue mode
* 2: Boots the system to a multi-user mode without networking functionality (some systems, like Debian, use this as a full-fledged mode)
* 3: Boots the system to a multi-user mode with networking functionality (some systems, like Debian, use this as a full-fledged mode)
* 4: Generally not used (sometimes it is the same as runlevel 5 or 3)
* 5: Boots the system to a full-fledged graphical multi-user mode (with networking, of course)
* 6: Reboots the system (to be switched to after booting)
* (s or S: Usually similar or equal to runlevel 1)

As the last runlevel is not always considered a real runlevel (it is then called an alias), the number of runlevels is usually seven, but arguably eight. You can switch between all runlevels after having booted, although 0 and 6 will (of course) require you to boot again before you can switch again. Switching between runlevels is usually done with the init command, like this:

[rechosen@localhost ~]$ init 3

The above command would (run as root or with root permissions) switch your system to runlevel 3, unless it's already running in runlevel 3 (replace the 3 with an other digit if you want to switch to an other runlevel). When switching between runlevels, init terminates the processes that were running in the old runlevel which should not run in the new one (these are zero processes when booting and all processes when shutting down or rebooting) and starts the processes that were not running in the old runlevel which should run in the new runlevel (these are zero processes when shutting down or rebooting, but when booting, it depends on the runlevel you're booting to). And now we can go on to the way init "knows" what to start and what to stop.

[b]What to start and what to stop?[/b]
When the init process is started by the kernel, it first looks in the /etc/inittab file to see what to do in case of a certain runlevel. This file usually tells init to look in the corresponding /etc/rcX.d/ directory, where X is the runlevel. For example, when booting to runlevel 5, init will run the scripts in /etc/rc5.d/ (please note (again) that this does not apply to all distros). These "scripts" usually are symlinks to the corresponding service management scripts in /etc/init.d/ (or /etc/rc.d/init.d/). But how can such a script understand whether init wants it to start or stop the service? Well, when init wants the script to start the process, it will run the script with "start" as the first argument. When wanting the script to stop the service, init will pass "stop" as the first argument. You can also do this yourself if you want to start or stop a service. For example:

[rechosen@localhost ~]$ /etc/init.d/ntpd stop

The above example would stop the ntpd daemon. To start it again use the following command:

[rechosen@localhost ~]$ /etc/init.d/ntpd start

Stopping and starting can usually be combined in the following way.

[rechosen@localhost ~]$ /etc/init.d/ntpd restart

This is useful in case you want a daemon to re-read its config files. Depending on the service the script was written for (and the script itself), other arguments may also be supplied.

Anyway, let's get back to the /etc/rcX.d/ directory. This directory is filled with files named like "K59somedaemon" and "S10anotherdaemon". I'll give a short explanation:

* "K" means "kill" and "S" means "start": The symlinks starting with "K" will be executed with a "stop" argument by init, and the symlinks starting with "S" will be executed with a "start" argument.
* The two digits after "K" or "S" don't mean anything really special, they are just used for sorting. Symlinks that need to be run before certain other ones should have a lower number than the other ones.
* The name of the daemon after it is actually not necessary for init, but it's good practice for sysadmins so they can instantly see what the symlink is for.

Finally, you should know that pretty much any distro has got some check somewhere to ensure that already running processes are not started again (which would result into two interferring processes, unless the daemon itself checks if there isn't an other instance running) and that already terminated processes will not be "reterminated". This is usually done by some special program or script that is called to do the actual starting.