Why System V init's split scripts approach is better than classical BSD
Originally, Unix had very simple startup and shutdown processes. The System V init system modernized them, resulting in important improvements over the classical BSD one. Although I've discussed those improvements in passing, today I want to talk about why the general idea behind the System V init system is so important and useful.
The classical BSD approach to system init is that there are
/etc/rc.local shell scripts that are run on boot. All daemon
starting and other boot time processing is done from one or the
other. There is no special shutdown processing; to shut the machine
down you just kill all of the processes (and then make a system
call to actually reboot). This has the positive virtue that it's
really simple, but it's got some drawbacks.
This approach works fine starting the system (orderly system shutdown
was out of scope originally). It also works fine for restarting
daemons, provided that your daemons are single process things that
can easily be shut down with '
kill' and then restarted with more
or less '
daemon &'. Initially this was the case in 4.xBSD, but
as time went on and Unix vendors added complications like NFS, more
and more things departed from this simple 'start a process; kill a
process; start a process again' model of starting and restarting.
The moment people started to have more complicated startup and
shutdown needs than '
kill' and '
daemon &', we started to have
problems. Either you carefully memorized all of this stuff or you
kept having to read
/etc/rc to figure out what to do to restart
or redo thing X. Does something need a multi-step startup? You're
going to be entering those multiple steps yourself. Does something
need you to kill four or five processes to shut it down properly?
Get used to doing that, and don't forget one. All of this was a
pain even in the best cases (which was single daemon processes that
merely required the right magic command line arguments).
(In practice people not infrequently wrote their own scripts that
did all of this work, then ran the scripts from
/etc/rc.local. But there was always a temptation to skip that
step because after all your thing was so short, you could put it
By contrast, the System V init approach of separate scripts puts
that knowledge into reusable components. Need to stop or start or
restart something? Just run '
/etc/init.d/<whatever> <what>' and
you're done. What the
init.d scripts are called is small enough
knowledge that you can probably keep it in your head, and if you
forget it's usually easy enough to look it up with an
Of course you don't need the full complexity of System V init in
order to realize these advantages. In fact, back in the long ago
days when I dealt with a classical BSD init system I decided that
the split scripts approach was such a big win that I was willing
to manually split up
/etc/rc into separate scripts just to get a
rough approximation of it. The result was definitely worth the
effort; it made my sysadmin life much easier.
(This manual split of much of
/etc/rc is the partial init system
I mentioned here.)