This document describes some other init systems, especially the "traditional" ones and describes their problems.

1. Introduction

some history, sysv, bsd,

minit, runit, initng, cinit, upstart

2. Implementations

List of current implementations as of 2006-12-12.

2.1. Linux Sys-V-Init

Debian Sid

/etc/inittab

"First script" /etc/init.d/rcS (specified /etc/init.d/rcS: Bourne shell script text executable

Runlevels: 0-6, different states

[9:51] hydrogenium:cinit-0.3pre6% /sbin/runlevel
N 2

Depending on runlevel, the init calls /etc/init.d/rc $runlevel.

This is manually configured in /etc/inittab

/etc/init.d/rc: Bourne shell script text executable

/etc/init.d/rc

Calls symlinks in /etc/rc?.d. Each runlevel a directory:

[9:51] hydrogenium:cinit-0.3pre6% ls -ld /etc/rc*.d
drwxr-xr-x 2 root root 4096 2006-12-01 16:56 /etc/rc0.d
drwxr-xr-x 2 root root 4096 2006-12-01 16:56 /etc/rc1.d
drwxr-xr-x 3 root root 4096 2006-12-01 16:56 /etc/rc2.d
drwxr-xr-x 2 root root 4096 2006-12-01 16:56 /etc/rc3.d
drwxr-xr-x 2 root root 4096 2006-12-01 16:56 /etc/rc4.d
drwxr-xr-x 2 root root 4096 2006-12-01 16:56 /etc/rc5.d
drwxr-xr-x 2 root root 4096 2006-12-01 16:56 /etc/rc6.d
drwxr-xr-x 2 root root 4096 2006-11-28 23:17 /etc/rcS.d

2.2. rlmanager: sys-v-init hack

rlmanager: one script to be executed, sources simply configuration

2.3. Gentoo Linux

no content yet

2.4. BSD init

Analyzed on FreeBSD. /etc/rc /etc/rc.d/ system services /usr/local/etc/rc.d/ user installed services Scripts may use values from /etc/rc.conf to check whether they should be started or not.

2.5. runit

Three stages: Script1, dependencies, Script3

2.6. Initng

no content yet

2.7. minit

Focus on being small. Needs libowfat. Log support through pipe.

3. Problems overview

3.1. Scripts

Scripts are slow. Startup time. Execution time. Unecessary overhead.

3.2. Sequential startup

In the old init systems there is no support of parallel execution. So if one services hangs at startup, the whole system has to wait (for instance a dhcp request). In the worst case this may result in a non-booting system. Systems with dependencies can start the gettys for login before, in parallel to or even after blocking services are started. The fact, that they are started means you can interact with the system, you can end looping or blocking services.

So sequential startup may not only be the reason for a pretty slow system, but also for an unmaintainable one.

3.3. Unecessary services

Many implementations try to do whatever-is-possible on boot, trying to cover every possible and impossible situation.

Portmap without any program that needs it.

Starting all installed services per default (Debian) vs. let the user choose what to start (Gentoo).

Nicht entfernte Altlasten ab und zu.

3.4. No dependencies

Systems without dependencies may result in a chaos state after booting up.

3.5. Only soft dependencies

The dependencies are used, but because of soft dependencies, services may be started although their dependency is missing.

3.6. Parallel init system debugging

In contrast to the old init systems, parallel executing init systems are much harder to debug. If the starting init systems does not have proper logging / reporting to the user (like cinit-0.2 has), the user may never find out, what happened and why.

3.7. Parallel / dependency checking init system with variable boot order

The boot order may be different each time you boot and is dependent on the success or failure of services. This way you can never tell exactly how and in which order they are executed. On multiprocessor machines, where processes may be truely executed in parallel, there is no order anymore, but there are n orders on n processors.

To solve this issue, init systems which support parallel execution should ship with some testing tools, that simulate a startup.

cinit will ship with such a tool in cinit-0.4.

4. References

no content yet