The NetBSD rc.d System

There's been a lot of hubbub the last few months about NetBSD's new rc.d system being the successor of 4.4BSD's. At the USENIX Annual Technical Conference 2001 in Boston, MA, I had the pleasure of sitting down to listen to Luke Mewburn of Wasabi Systems discuss the new rc system NetBSD introduced in their operating system in the 1.5 release earlier this year.

In general, the presentation gave me the feeling that NetBSD really did explore all options possible for making rc.d more flexible. They looked at the original 4.4BSD system, which was, for the most part, untouched in NetBSD, FreeBSD, and OpenBSD, in addition to Solaris 7's System V rc system. They fleshed out everything on the mailing lists.

Th design considerations for the new system aimed at overcoming three issues in the 4.4BSD rc.d scheme. First, system admins couldn't control the order in which daemons started up. Second, there was no easy way to control an individual daemon after the system was booted -- in other words, daemons either had to provide their own interface to stop, restart, or check the status of the daemon, or they didn't provide one. When they did, it sometimes took forever to figure out what the specific commands were. Third, Luke's presentation noted that the 4.4BSD system didn't really cater to third-party additions, especially for inserting them into arbitrary points in the boot sequence. In my opinion, however, it provides just fine for these third-party daemons, EXCEPT when they needed to be inserted somewhere before the end of the rc boot sequence. So again, NetBSD's new rc.d system is the logical expansion over the age-old 4.4BSD system.

After the design (which I'll explain below) was determined, NetBSD next considered the requirements of their new system. Preserving the current /etc/rc.conf was one of the requirements I had in mind, and the NetBSD developers had agreed. After all, doing otherwise would break countless systems, and there doesn't really seem to be a better way to store central configuration variables especially given that rc is a shell script system.

Another requirement of the new system was that it support dynamic dependency ordering. This is very important because it will avoid the need to edit third-party (and other) startup/shutdown scripts and the need for an arcane ordering method e.g. "S99imapd.sh". A dynamic ordering method will allow an rc scripter to worry only about the orders that are relevant for a particular service. As Luke said in his paper (referenced below), if service C depends on B which depends on A, and I have a new service D to install that must start after A and before C, then I want to specify it in these terms, without having to worry about whether it starts before B, after B, or simultaenously with B. NetBSD considered several approaches to implement a dynamic ordering method, and in the end they chose a dedicated program to handle it.

One thing that I've always found annoying about rc scripts on System V style systems is that the majority do not share any code among them. NetBSD felt this was a maintenance nightmare, and in their words, "We have a C library and common Makefile fragments, so why not common shell functions?"

NetBSD also decided that arbitrary and mandatory runlevels would not help system administrators manipulate services.

Given the design considerations, the new rc system was laid out as follows:

/etc/rc Good old rc startup driver script. /etc/rc.conf The usual central config file. /etc/rc.subr Central subroutines for rc scripts. /etc/rc.shutdown Shutdown script a la /etc/rc. /etc/defaults/rc.conf Defaults for rc.conf. /etc/rc.d/foo.sh New rc scripts go here, including the old monolithic /etc/rc.*. /etc/rc.conf.d/foo.conf Config files for the individual rc scripts. /sbin/rcorder Dedicated program to generate dynamic dependency ordering.

As usual, when init(8) brings the system up, it starts /etc/rc. But this time, instead of /etc/rc calling other /etc/rc.* scripts, rc calls rcorder on /etc/rc.d/*, and then calls each script returned by rcorder with an argument of "start". Similarly, when shutdown time comes, /etc/rc.shutdown is called by shutdown(8). Again, it runs rcorder(8) and calls the resulting scripts with an argument of "stop".

Each rc script is required to have "start" and "stop" arguments, and other optionally supported standard arguments include "restart", "status", and "rcvar". The first four should be pretty obvious in purpose and function to most of DaemonNews's readers; the fifth, "rcvar", displays which /etc/rc.conf variables are relevant to the service, a very handy tool to help system administrators figure out what they need to configure.

All in all, the new rc system is a logical improvement in the BSD way of doing things. That is, the BSD way is to do things the best way possible, given all circumstances and design considerations. And NetBSD has done exactly that with their new rc system. I personally applaud their efforts, especially since they have proven willing to help other system vendors adopt it. One less difference for system admins to remember is one more reason to use UNIX systems!

More details are available in Luke Mewburn's paper that he presented at the USENIX Annual Technical Conference.