Overview of Unix Process Managers

When you first turn on your computer the BIOS kicks in and searches for instructions on your master boot record or MBR. From there it is able to locate the boot loader which in turn figures out which kernel to run and then loads it into memory and that is the point you start actually running your flavor of UNIX. At this stage your computer is just running a kernel and has no interactivity or running services.

You are most likely used to using your computer to do something, and to do that, you need to run processes. While at this point you could have your computer launch a shell, you would still have a lot of setting up to do such as mounting hard drives, bringing up your network adapters, starting services, launching a GUI or what ever else you want to do. This is tedious and beyond the ability of most people so instead of running a shell the first process your computer runs is some kind of process manager. Traditionally this has been the init program which is the parent of every process that is executing.

Init is controlled by a handful of scripts that in turn launch other processes to give your computer it functionality. Which level of functionally you want when you start up your computer is usually controlled by runlevels which number from 1 to 6 and that determines which scripts to run. What each number means, depends on which type of Unix you are using and even varies from flavor to flavor of that Unix type. As an example you might want your computer to have different modes and most systems come with modes for single user, console, gui, and networkless mode which could be used in different scenarios without having to spend a lot of time adjusting your environment.

Like most things in the Unix world you are given a choice of which flavor you would like to use and each has its own pros and cons. This is not meant to be documentation on how to configure each of the init systems and instead you should first refer to your distro’s documentation as they probably have a system in place already which would confuse other users if subverted and their system is generally more convenient anyway.

I am going to try give an overview of each of the process managers with out getting into the scripts that it launches or how to configure them. I will try to start with the more common ones, however as we go on they start to get more advanced, and thus, more interesting.

SystemV Style

This name comes from one of the first versions of AT&T Unix that was released in 1983 however there are still a lot of distros today that use this system for configuration such as Redhat, Debian, SUSE, and Mandriva. When the SysV runlevel is first started up it checks the file /etc/inittab to determine which runlevel to enter and from there executes the scripts found in /etc/rc.d/{rc.local,init.d,rc0.d,rc1.d,…} which each of the numbered directories storing the scripts for the 6 different runlevels. The actual scripts are usually stored in a separate directory and then symbolically linked into multiple directories for each runlevel that it is to be run in. The links usually have a name like S22network, or K50nfs. The S and K prefix respectively indication that it is to be started when the system enters that runlevel or killed when the system leaves that run level. The two digit number indicate what priority the script should be run with the lower numbers being run first.

BSD Style

The BSD style init is used right now by Slackware and of course most of the different BSDs. The BSD style is often cited as the easiest to use and I have even heard that it was setup in a way that is closest to the way humans think. That means if your still thinking about runlevels right now you might not be human because they don’t exist in BSD Style init systems. Instead of having separate directories for each of the runlevels, there are files that need to be edited to allow different services to run, typically rc.conf. The pitfall to this is that if you make a mistake that is unparsable in the file you might not be able to boot up your machine.

Hybrid BSD/SysV style

Some distros like the best of both worlds and Gentoo comes to mind as an example. It has runlevels like in SysV and one file to edit like in BSD. This makes it easier to develop tools to manage the SysV links while at the same time making it easier for new users to configure services.

Upstart

Upstart is one of the new players in the field. Right now it is in use by Ubuntu, Maemo, and the new Google OS. One of the reasons why Upstart has been adopted so fast is partly because it can support unmodified SysV init scripts out of the box while at the same time supporting new startup methods that can be gradually incorporated as they are written or converted. Instead of using a traditional synchronous ,and thus blocking, scheduling scheme, Upstart uses an event based system which allows it to respond to events asynchronously that are generated on the fly. This is becoming more and more useful as the newer Linux distributions have to allow support for newer hardware that might not even be attached at startup such as portable USB drives or in the case of hardware that requires firmware to be loaded into the device midway it its initiation process.

Launchd(OSX)

I would say that Launchd is the easiest to talk about since at the moment it is only really used by OSX so there is one way of doing things. Apple runs this as the first process after the kernel is booted and it replaces a lot of services that would traditionally be needed such as cron, watchdog, and of course the actual service launcher. Right now all of the old services are still included with OSX, but don’t count on them for long since launchd has all the functionally that the aforementioned services offer. In addition to controlling the service launches, launchd is also responsible for booting the system. One of the problems with launchd is that is designed to run services only when needed, which is nice, but if those services have dependencies it is difficult to make them run in a particular order. If you want this to happen you have to rewrite the service to wait until its dependency is met which really isn’t a solution. There is also a application to manage your services in one central way which is really convenient compared with searching all the places a startup script can reside, (’/etc/rc/’,’/System/Library/LaunchAgents’,’/Library/LaunchDaemons')

Service Management Facility(Solaris)

SMF is a replacement for init.d scripts that are commonly used in Linux distributions. SMF is what I consider to be the powerhouse of the different process managers. In it dependencies are tied to other services so it is easier for SMF to start services in parallel without requirement problems. Another cool feature of SMF is the service management can be delegated to nonroot users on a service by service basis as well as configured to be run as a nonroot user easily. If you are running a cluster of Solaris servers, there is also support for transitioning services from one machine to another when they fail to make it easier to build redundant systems. In past versions of Solaris, service configuration was a messy business but SMF replaces all this with a constant way to administer all of your services.