When running to a run level does it execute previous run levels?

Question

If I tell my system to go to run level 3 does that mean that it first runs through run level 0, 1, 2, and then finally runs through run level 3?

I thought the answer to this question was yes. But when I look on my RHEL 6 system I see that many of rcX.d directories contain same symbolic links.

In My /etc/rc.d/rc0.d/

[root@centos6 rc.d]# ls -lah /etc/rc.d/rc0.d/
total 8.0K
drwxr-xr-x.  2 root root 4.0K Jun 27 11:59 .
drwxr-xr-x. 10 root root 4.0K Jul  9 15:06 ..
lrwxrwxrwx.  1 root root   13 Jun 12 13:02 K05atd -> ../init.d/atd
lrwxrwxrwx.  1 root root   14 Jun 12 13:01 K10cups -> ../init.d/cups
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx.  1 root root   18 Jun 12 12:51 K15svnserve -> ../init.d/svnserve
lrwxrwxrwx.  1 root root   14 Jun 12 10:58 K25sshd -> ../init.d/sshd
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K30postfix -> ../init.d/postfix
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K50dnsmasq -> ../init.d/dnsmasq
lrwxrwxrwx.  1 root root   20 Jun 12 10:57 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx.  1 root root   15 Jun 12 10:57 K60crond -> ../init.d/crond
lrwxrwxrwx.  1 root root   25 Jun 27 11:59 K65vboxadd-service -> ../init.d/vboxadd-service
lrwxrwxrwx.  1 root root   17 Jun 27 11:58 K70vboxadd -> ../init.d/vboxadd
lrwxrwxrwx.  1 root root   21 Jun 27 11:59 K70vboxadd-x11 -> ../init.d/vboxadd-x11
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K73winbind -> ../init.d/winbind
lrwxrwxrwx.  1 root root   19 Jun 12 12:26 K74haldaemon -> ../init.d/haldaemon
lrwxrwxrwx.  1 root root   26 Jun 12 10:58 K75blk-availability -> ../init.d/blk-availability
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K75netfs -> ../init.d/netfs
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K75udev-post -> ../init.d/udev-post
lrwxrwxrwx.  1 root root   24 Jun 12 12:26 K84NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx.  1 root root   24 Jun 27 11:59 K84wpa_supplicant -> ../init.d/wpa_supplicant
lrwxrwxrwx.  1 root root   19 Jun 12 10:58 K85mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx.  1 root root   20 Jun 12 12:25 K85messagebus -> ../init.d/messagebus
lrwxrwxrwx.  1 root root   20 Jun 12 10:58 K87multipathd -> ../init.d/multipathd
lrwxrwxrwx.  1 root root   21 Jun 12 10:57 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K88auditd -> ../init.d/auditd
lrwxrwxrwx.  1 root root   15 Jun 27 11:59 K88iscsi -> ../init.d/iscsi
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K88rsyslog -> ../init.d/rsyslog
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K89iscsid -> ../init.d/iscsid
lrwxrwxrwx.  1 root root   21 Jun 12 13:01 K89portreserve -> ../init.d/portreserve
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx.  1 root root   17 Jun 12 11:15 K90network -> ../init.d/network
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx.  1 root root   18 Jun 12 10:57 K92iptables -> ../init.d/iptables
lrwxrwxrwx.  1 root root   22 Jun 12 10:58 K99lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx.  1 root root   17 Jun 12 11:15 S00killall -> ../init.d/killall
lrwxrwxrwx.  1 root root   14 Jun 12 11:15 S01halt -> ../init.d/halt
lrwxrwxrwx.  1 root root   15 Jun 26 12:32 S95jexec -> ../init.d/jexec

And in /etc/rc.d/rc1.d/ I see the same set of symbolic links as in rc0.d plus extra links. This seems to indicate that the directories rc0.d, rc1.d are independent and that to get to run level 1 it does not execute the stuff in run level 0. Which means that bad things can happen if some how the symbolic links in rc0.d were not exactly replicated in rc1.d, ... etc.

So how does it really work? Does it just scan the files in a specific rc.X dir or run through all rc.X dirs that have a lower level than rc level passed to init?

[root@centos6 rc.d]# ls -lah /etc/rc.d/rc1.d/
total 8.0K
drwxr-xr-x.  2 root root 4.0K Jun 27 11:59 .
drwxr-xr-x. 10 root root 4.0K Jul  9 15:06 ..
lrwxrwxrwx.  1 root root   13 Jun 12 13:02 K05atd -> ../init.d/atd
lrwxrwxrwx.  1 root root   14 Jun 12 13:01 K10cups -> ../init.d/cups
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx.  1 root root   18 Jun 12 12:51 K15svnserve -> ../init.d/svnserve
lrwxrwxrwx.  1 root root   14 Jun 12 10:58 K25sshd -> ../init.d/sshd
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K30postfix -> ../init.d/postfix
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K50dnsmasq -> ../init.d/dnsmasq
lrwxrwxrwx.  1 root root   20 Jun 12 10:57 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx.  1 root root   15 Jun 12 10:57 K60crond -> ../init.d/crond
lrwxrwxrwx.  1 root root   25 Jun 27 11:59 K65vboxadd-service -> ../init.d/vboxadd-service
lrwxrwxrwx.  1 root root   17 Jun 27 11:58 K70vboxadd -> ../init.d/vboxadd
lrwxrwxrwx.  1 root root   21 Jun 27 11:59 K70vboxadd-x11 -> ../init.d/vboxadd-x11
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K73winbind -> ../init.d/winbind
lrwxrwxrwx.  1 root root   19 Jun 12 12:26 K74haldaemon -> ../init.d/haldaemon
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K75netfs -> ../init.d/netfs
lrwxrwxrwx.  1 root root   24 Jun 12 12:26 K84NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx.  1 root root   24 Jun 27 11:59 K84wpa_supplicant -> ../init.d/wpa_supplicant
lrwxrwxrwx.  1 root root   19 Jun 12 10:58 K85mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx.  1 root root   20 Jun 12 12:25 K85messagebus -> ../init.d/messagebus
lrwxrwxrwx.  1 root root   20 Jun 12 10:58 K87multipathd -> ../init.d/multipathd
lrwxrwxrwx.  1 root root   21 Jun 12 10:57 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K88auditd -> ../init.d/auditd
lrwxrwxrwx.  1 root root   15 Jun 27 11:59 K88iscsi -> ../init.d/iscsi
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K88rsyslog -> ../init.d/rsyslog
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K89iscsid -> ../init.d/iscsid
lrwxrwxrwx.  1 root root   21 Jun 12 13:01 K89portreserve -> ../init.d/portreserve
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx.  1 root root   17 Jun 12 11:15 K90network -> ../init.d/network
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx.  1 root root   18 Jun 12 10:57 K92iptables -> ../init.d/iptables
lrwxrwxrwx.  1 root root   22 Jun 12 10:58 S02lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx.  1 root root   26 Jun 12 10:58 S25blk-availability -> ../init.d/blk-availability
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx.  1 root root   15 Jun 26 12:32 S95jexec -> ../init.d/jexec
lrwxrwxrwx.  1 root root   16 Jun 12 11:15 S99single -> ../init.d/single

Answer 1

If I tell my system to go to run level 3 does that mean that it first runs through run level 0, 1, 2, and then finally runs through run level 3?

No, it does not. Runlevels are not consecutive in that manner.

Case in point: runlevel 0 is usually the "shutdown" runlevel, which stops all services and eventually halts (and possibly powers off) the system. It wouldn't be very good if, to get to a fully running system, init first went into runlevel 0.

That said, there is usually a progression during the boot process. The kernel initializes in runlevel 1, then passes control to init which normally is configured in such a way that it goes into runlevel 2 (multi-user without networking) followed by runlevel 3 (fully operational text mode) and possibly runlevel 5 (fully operational graphical mode). But this is actually completely configurable, and the specifics of what goes into which runlevel is mostly by convention. I think at least in the past, Debian has used runlevel 4 for fully operational graphical mode, for example, and on my Debian Wheezy, runlevels 2 and 3 appear to be identical (diff <(ls /etc/rc2.d) <(ls /etc/rc3.d) outputs nothing). Exactly what each runlevel corresponds to is up to the administrator.

Also by convention, runlevel 6 is usually set up to reboot the system; you can jump directly to runlevel 6 from e.g. runlevel 1, particularly during system maintenance if something prevents the OS from booting normally.

It's also worth noting that non-Linux systems may have different ideas of what the different runlevels are for, or have a different number of runlevels available. The concept is likely pretty much universal in the *nix world, but the implementation and actual use can differ wildly.

All in all, "runlevels" is simply a convenient way of grouping related processes and system state into manageable bundles that can be selected by the administrator. (And as an aside, Windows has a very similar concept with its fail-safe mode, fail-safe with networking, fail-safe with command prompt, normal boot, and so on.)

Answer 2

When you switch runlevel, the only things executed are the scripts in /etc/rc.d/rc${NEW_LEVEL}.d/.

This means that you are right: Every rc*.d directory needs to be able to handle all of the process/service changes when switching from another runlevel. So every rc directory contains a full set of scripts for reaching that runlevel.

Say you're switching to runlevel 3. The /etc/rc.d/rc3.d/K* scripts will attempt to kill any processes that were running in whatever your previous runlevel was (could be any number), and /etc/rc.d/rc3.d/S* scripts will start any processes that need to be started (and weren't already started in the previous runlevel).

Clearly, managing all of these symlinks would be a real pain, so there are utilities to help manage this. On Debian and Ubuntu (at least, maybe others), you can use update-rc.d to selectively enable/disable scripts found in /etc/init.d, or to set them up to "default" or recommended settings for each script. This will create and update all the symlinks for you, to reflect any configuration changes you want to put in place. On CentOS, I understand you can use ntsysv or chkconfig to do the same thing.

Effectively, you never touch the files in /etc/rc*.d/ (or /etc/rc.d/rc*.d/) yourself; you always use the tool (eg. update-rc.d, ntsysv, chkconfig) to make any changes.