13. init

The first process started on a Unix system is called init. It typically starts by rummaging through /etc/inittab to see what processes should be started.

This often begins with running a script named something like /etc/init.d/rcS which controls how to start up the whole variety of system services such as configuring networking, logging, running file servers like NFS , Coda , and SAMBA, as well as other daemons such as mail servers , web servers , database servers, and such.

Once the system services are started, init will start up getty processes to allow users to log in. There are two traditional approaches to it:

• BSD Init

  Where the startup of services is controlled by putting those services into a shell script that is executed.

• System V Init

  Where services each have a script, commonly placed in /etc/init.d/ or /etc/rc.d/, which then are linked into a set of directories, one for each run level.

  The startup script looks at all the scripts in the runlevel's directory, and invokes them in the order indicated.

The SYSV approach is not particularly elegant, but it is straightforward to write programs to predictably manipulate the set of startup scripts, which is not practical with the BSD approach. Proponents for both approaches can easily find instances where their favorite approach is to be preferred.

Here are links to some of the "traditional" init implementations:

• Linux SysVinit

• OpenBSD init

• FreeBSD init

People have built alternatives, trying to fulfil one improvement or another. Some have built "minimalist" alternatives to init, in one case resorting to assembly language to make it as tiny as possible. The more interesting alternatives try to improve functionality and/or reliability:

• serel - fast boot software

  Starting up system services is typically the most time consuming parts of starting up a Unix system. Traditional init starts up processes serially, one after another, when often they do not truly depend on one another.

  For instance, ntp depends on having network services running, but then goes off and queries remote servers to get updated time information. It would be quite reasonable to spawn ntpd as soon as the network is up, and let it proceed in the background with those queries.

  Similarly, the JBoss Java application server requires that there be some network functionality working, but there is no need for other services that do not use JBoss to wait for it. The SN news server does some reorganization of the news spool at startup; nothing needs to wait for that to complete.

  serel tries to maximize the degree to which startup processes may be spawned in parallel.

• Linux Boot Scripts

  Richard Gooch has made up a dependancy-oriented alternative to the traditional service startup approaches, based on a program called need.

  Each service that is to be run has its own script in /sbin/init.d , and init runs each, in random order. Each service script contains a set of need commands indicating what services it depends on. The dependancies get run first.

  A provides command addresses the situation where a program needs a "logical service" that might be satisfied by multiple "actual services." For instance, there are several mail transfer agents, including Sendmail , Postfix , and qmail , and a service that "needs mail services" should not explicitly depend on any one of them, but rather on having a MTA service that may be provided by any of these applications.

  Unfortunately, it does not appear to address the parallelism matter, where it would be attractive to start up services that are not mutually dependent concurrently.

  The init in the Mastodon distribution takes a very similar approach.

• minit

  A minimal init.

• runit - minimal replacement for sysvinit

• Bizarre Sources, Corp.

  twsinit is a version of init that is written mostly in IA-32 assembler, with the result that it is extremely tiny. Does this solve any real problem? Who can tell?

• svscan as process 1

  Using DJB's svscan tool from "daemontools"

  svscan starts and monitors a set of processes at some directory base. It starts a supervise process for each subdirectory, running the program referenced in the subdirectory. Every five seconds thereafter, svscan checks for both new subdirectories and for subdirectories where the supervisor has "died," and starts up new supervisors.

  This would certainly address the "parallelism" side of things, and also has the ability to (try to) ensure that services are always running. Unfortunately, it does not offer a way to address dependancies of some services on others.

• systemd

• GNU Shepherd

  Aka GNU dmd aka GNU Daemon Shepherd is a service manager providing a dependency-based daemon management system, implemented in Scheme, originally implemented for use with GNU Hurd, but also usable with Linux.

    [Unit]
    Description=Emacs: the extensible, self-documenting text editor
               
    [Service]
    Type=forking
    ExecStart=/usr/bin/emacs --daemon
    ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
    Environment=SSH_AUTH_SOCK=%t/keyring/ssh
    Restart=always
               
    [Install]
    WantedBy=default.target