Under UNIX-like operating systems, there are several ways to manage long-running processes such as daemons. Process management is a crucial aspect of system maintainance and therefore it’s one of the aspects to take into account when planning a deployment. Since available solutions are getting more and more complex and specialized, I thought of writing a series of articles to recap the state of the art and draw up a comparative analysis.
This post deals with two system-wide alternatives, sysinitv and Mac OS X’s launchd: the first represents the tradition, while the latter represent innovation. Feel free to use comments to share your tips.
System V init
Also known as sysinitv, it’s the historical choice for most unices. Every OS has customized its own version so there’s no common standard. First process, typically /sbin/init reads config in /etc/inittab and executes a series of commands, depending on which runlevel is currently set.
In typical configurations, init launches a main rc script on runlevel change (boot sequence runlevel, default multiuser runlevel, etc), which in turn runs all the initialization scripts in a runlevel-specific folder. For example, in Redhat Linux each system service has an init script in /etc/init.d/. These init scripts respond to a number of actions that can be passed as parameter, for example /etc/init.d/sendmail start runs a function that starts sendmail daemon. Typical actions include: start, stop, restart, status. Some scripts implement specific actions: for instance apache service implements reload action, which does a graceful signal-based reload. Furthermore, most OSes include additional dependency information in those scripts and import script configuration directives from external files (/etc/sysconfig/ on Debian, SuSE, etc, /etc/conf.d/ in Gentoo).
When rc scripts is ready to process init scripts, it looks in appropriate runlevel folder (in RedHat Linux and derivatives its /etc/rc.d/rc<runlevel>.d/, Gentoo has /etc/runlevels/<runlevel>/, etc) and executes entries which are symlinks to the actual /etc/init.d scripts.
Most of these systems use a specific naming convention for these symlinks, to define order of execution (scripts are run in alphabetic order) and action to be passed as parameter. For example, on RedHat-style systems, scripts are named as S<NN><service> or K<NN><service>, where NN is a number from 00 to 99. S means start action (ie. /etc/rc.d/rc3.d/S60sendmail start), while K means stop action. In other systems such as Gentoo, order of execution is determined dynamically by dependency information (requires additional computing and dependency caching).
Operating systems typically implement command-line, ncurses-based or X11-based tools to manage adding and removing items from runlevels: chkconfig under RedHat/CentOS, update-rc.d under Debian, rc-update under Gentoo, boot up manager (bum) under Ubuntu.
Pros: well known, easy for unix admins, easy to add new custom scripts.
Cons: no common standard, no parallel execution (except for Gentoo), no support process monitoring (ie. restarting daemons on crash).
It’s installed by default on Mac OS X 10.4 (Tiger) and later. Once launchd is run by the kernel, it runs /etc/rc (a BSD-style system wide initialization script) and scans/System/Library/LaunchAgents and /Library/LaunchDaemons for plist files. Each plist contains a series of properties that define behaviour of launchd and customize run setup (command parameters, working directory, process owner, resource limits, etc). Launchd monitors processes and dynamically acts to adapt process status to requirements defined by configuration. This includes: running process automatically at boot, respawning process on unexpected quit, starting and stopping process upon several conditions (cpu load, network status, filesystem mounts, file presence, time schedule, shutdown, sleep, etc).
Finally, launchd companion is user tool launchctl, which interacts with launchd through a socket and allows administrator to send in requests like start, stop, list, limit, shutdown, etc.
Pro: amazing configuration directives, powerful extension mechanism, post-spawn process monitoring and usage management, scheduled actions (as in cron), stdio-to-inet support as inetd, can add processes without configuration files.
Cons: configuration plists are an Apple-world standard, many great features are Mac OS X specific, strict process launching requisites (see launchd.plist manpage), no support for configurable dependencies, no support for custom process signaling, complex logic may lead to unexpected results.