Concurrent boot sequence

Posted by mcortese on Thu 26 Feb 2009 at 15:11

In the quest for the fastest boot ever (see Booting Debian in 14 seconds), you may want to consider setting the variable CONCURRENCY=shell in /etc/default/rcS, recalling from your your theoretical studies that "Parallel is faster than Sequential."

The results you get can fall short of your expectations if you don't also reorder the boot sequence. And if you have installed readahead, you may even have unpleasant surprises...

When you install readahead, it places an init script in /etc/init.d and its symbolic link /etc/rcS.d/S02readahead. As long as the scripts in /etc/rc?.d directories are executed in lexicographic order, this script is executed after S02mountkernfs. This is fine, because readahead actually depends on /proc being mounted, which is exactly what mountkernfs does.

But what happens when, as a consequence of CONCURRENCY=shell, all scripts with the same priority are run in parallel? Then readahead and mountkernfs, both with priority 02, are launched together, and the latter may or may not mount /proc before the former requires it.

Reordering rcS.d

In fact, readahead must be run after mountkernfs (priority 02) but before udev (priority 03). Lacking fractional priorities, the only solution is to "promote" udev to priority 04, which, in turn, triggers a "+1" promotion for all the subsequent scripts that depend on each other, namely: mountdevsubfs (from 04 to 05), and keymap and bootlogd (from 05 to 06).

Now your boot sequence is sane, but still suboptimal. To get any benefits from the concurrency, as many scripts as possible must share the same priority, so that they can be parallelized. Opportunities for optimization can be found in six different places:

• hdparm and hwclockfirst only depend on mountdevsubfs (priority 05), so they can be moved to priority 06.
• Even before that, procps does not depend on anything, and can be comfortably run just after readahead, at priority 04, in parallel with udev.
• ifupdown-clean, module-init-tools, mtab, and udev-mtab depend only on the root file system being clean, thus they can all share priority 12, just after checkroot.
• Another group of scripts that can go along together is the trio x11-common, urandom and ifupdown: they all need a stable local file system, but do not need any network capability. Their logical priority is 39, just before networking.
• Since 39 is also the default priority for readahead-desktop, and since I think its pre-loading goal is better achieved if left running alone, I suggest anticipating its priority to 38.
• Finally, the group console-screen, alsa-utils, sudo, and bootmisc can share the priority 50.

Please note that I have intentionally skipped hwclock since I never got to understand what it is intended to do that hwclockfirst doesn't already do. In any case, I got rid of the time-consuming hwclock and hwclockfirst all together when I compiled RTC support into the kernel.

To summarize, this is how your /etc/rcS.d should appear, with same-priority scripts grouped on the same line:

S01glibc
S02hostname  S02mountkernfs
S03readahead
S04udev      S04procps
S05mountdevsubfs
S06bootlogd  S06hdparm  S06hwclockfirst  S06keymap
S10checkroot
S12ifupdown-clean  S12module-init-tools  S12mtab  S12udev-mtab
S30checkfs
S35mountall
S36mountall-clean
S37mountoverflowtmp
S38readahead-desktop
S39ifupdown  S39urandom  S39x11-common
S40networking
S45mountnfs
S46mountnfs-bootclean
S50alsa-utils  S50bootmisc  S50console-screen  S50sudo
S99stop-bootlogd-single

Reordering rc2.d

Having done such a nice job with rcS.d, what about optimizing rc2.d as well? The goal here is different, though. What you should really be interested in, is to bring up the login screen as soon as possible, and let all the rest follow at its own pace.

I'll assume that you have GDM to take care of your login (configuration of other display managers should be even easier, thus is left as exercise for the reader).

As Arjan and Auke teach us the first think to do is to identify the "critical path" that leads to S30gdm as soon as possible. Here it is:

S10sysklogd -> S12dbus -> S24hal -> S30gdm

• With the exception of system-tools-backend which might be of use for the upcoming GDM session, and thus deserves priority 31, most of the remaining scripts can share priority 40.
• The scripts saned and cups, which depend on avahi-daemon, must be moved to priority 45.
• You can leave cron and anacron at their default priority of 89 because, given their very nature, there is no expectation at all about the time when they are run.
• At the far end of the boot sequence, the last scripts must be rearranged a little: rmnologin and rc.local should be run at 89, i.e. just before the "really last" scripts stop-bootlogd, stop-readahead, and possibly bootchart.

Again, this is a summary of the /etc/rc2.d directory after the cure:

S10sysklogd
S11klogd
S12dbus
S24hal
S30gdm
S31system-tools-backend
S40acct  S40avahi-daemon  S40openbsd-inetd  S40ssh
S45cups  S45saned
S89anacron  S89cron
S98rc.local  S98rmnologin
S99bootchart  S99stop-bootlogd  S99stop-readahead

Please note that, depending on the software you have installed, your list may be different. For example, you might have xinetd instead of openbsd-inetd, and so on.

I hope this works for you as it worked for me, polishing away another 3 seconds from my boot time!

This article can be found online at the Debian Administration website at the following bookmarkable URL (along with associated comments):

• http://www.debian-administration.org/article/Concurrent_boot_sequence

This article is copyright 2009 mcortese - please ask for permission to republish or translate.