On to better booting

More than a few Linux distributions have pulled up their stakes in the decades old System V method of booting and quietly moved to a better way of booting. Better, faster, easier to maintain, and less prone to problems. I say "quietly" not to imply that there haven't been announcements, banners waving, and proper cheers from some segments of the Linux user community, but to emphasize how little disruption has occurred and how little those of us who have been living in the slower-to-change Linux environments have had to pay attention. But the changes are nothing short of huge.

In a dramatic move toward reducing the boot time for Linux systems, two contenders for system start-up have emerged in recent years. One goes by the name "Upstart" (get it? -- "start up" with the syllables reversed). The other is called systemd (for system daemon). If you hadn't spotted a dramatic change in your Linux systems, you're probably using one of the more conservative Linux systems. The difference between RedHat and Fedora today might really surprise you.

Both contenders -- Upstart and systemd -- are very much in use today as is the older System V (say "system five") initialization process, now generally referred to as "SysVinit". So, depending on what particular "brand" of Linux system you happen to be working with, some combination of these three initialization services could be controlling your boot process.

Both Upstart and systemd (pronounced "system dee") represent attempts to address long-standing problems in the now traditional SysVinit system -- such as slow booting and dependencies between services. Slow booting in SysVinit is due, at least in part, to the fact that the entire process depends on a series of shell scripts which themselves tend to be slow (forks, after all, consume resources). In addition, the process is required to start each service in sequence before moving to the next start script. Both Upstart and systemd move way beyond these drawbacks yet are still compatible with SysVinit, so your system could be using one of the newer initialization systems while still launching some of your services using the older rc#.d scripts. If so, you should notice a dramatic improvement in boot time for any server which uses either of the new systems.

The reason that system using Upstart or systemd might continue to run SysVinit is that daemons need to be patched to work with the new initiation processes. For most services that start when you are running an Upstart or a systemd based distribution, this will be done already. The services that install with or get added to your system will already know how to work with the new boot methodology.

Of the two contenders for Linux booting, systemd appears to be in the lead. It is the later of the two to emerge. Both Upstart and systemd share some of the same advantages -- much faster boot times, and less dependency on starting processes in a particular order. It looks like the crowd lining up behind systemd is growing fast. With Fedora, OpenSUSE, Mandiva, Arch, Debian, Frugalware -- Did I forget anyone? And RedHat will probably be joining with the release of RedHat7. Gentoo has its own next generation rc system called OpenRC, which competes with both systemd and upstart, but provides its users with the option of installing systemd. Ubuntu seems to be sticking with Upstart.

While Upstart and systemd have very similar goals, they are quite different implementations of the boot process. Upstart works in an event-based manner, responding to things that happen on a system, while systemd provides a modern, fast, and flexible way to deal with process dependencies.

Which am I using?

One of the ways that you can tell if your Linux system is using one of these new initialization systems is to look at the contents of /etc/rc.d/rc5.d. On a traditional sysVinit system, you will probably see between 50 and 100 scripts. On a system running Upstart or systemd, you will may see a dozen, maybe fewer. My Fedora 17 system has six. These are the services that are not converted to the new boot model.

Another way is to ask. Type "which systemd". If that doesn't work, try "man Upstart". Of course, if your system takes more than about 30 seconds to boot, you probably shouldn't even bother looking.

Systemd

Systemd is referred to as a system and session manager for Linux. It's compatible with both the old SysVinit scripts and with LSB (Linux Standard Base). It uses aggressive parallelization. That means that it starts lots of processes at the same time rather than waiting for one to be available before starting the next.

It also uses socket and D-Bus (message bus) activation for starting services. This means that services can start in response to things that happen on a network socket.

Systemd implements control groups (cgroups) to keep track of processes and supports snapshotting and restoration of the system state. This means that, should you have a pile of services running (through any means) and find you have to go into single user mode, you can snapshot the process state and then go back to it when you come back from single user mode. That's really quite impressive when you think about it.

As a sysadmin, the move to systemd will end up saving me a lot of trouble. I will no longer have to worry about the dependencies between services and creating start-up scripts with names that place them in the proper alphanumeric order so they don't start up too early or too late in the boot process. If the system notices that some service has gone down, it will restart it and there's a good chance that no one else will even notice.

The central characteristic of systemd that makes it work so well (and enables its high level of parallelization) is that it creates the sockets that provide for communications between services. Yes, that means that the binding process is done in init -- not the daemons. So, init doesn't need to wait for services to do this on their own. It hands the sockets to the services when they are fully launched. Where SysVinit will only start a service once services it depends on are running (because of sysadmins careful naming of their start-up scripts), systemd moves ahead without concern.

An example is that of syslog and D-Bus (desktop bus -- and interprocess communications mechanism used in the Linux kernel. SysVinit will not launch D-Bus until the syslog service is running. Systemd will create /dev/log and launch both D-Bus and syslog at the same time.

Because systemd both creates and maintains the sockets, it can re-launch services without causing services that were connected to those sockets to lose their connections. Again, what an impressive innovation! Though I understand some credit belongs to Apple due to similar innovations in its launchd.

What this means to Linux admins is that, with systemd, our concerns about slow boots, service dependencies and service failures are going to be dramatically reduced.

I remember back to the days in which the boot process was controlled by two big scripts -- /etc/rc and /etc/rc.local. The System V start-up system that, for me, became a part of my life with SVR4 (the big merger between System V and BSD) was a welcome change and I quickly grasped the steps in the process and tended to my rc scripts. What I'm now seeing in systemd has me saying "Wow!!!!!". No doubt about it, this is the better way to boot!

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies