[9:51] hydrogenium:cinit-0.3pre6% /sbin/runlevel N 2
This document describes some other init systems, especially the "traditional" ones and describes their problems.
some history, sysv, bsd,
minit, runit, initng, cinit, upstart
List of current implementations as of 2006-12-12.
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
rlmanager: one script to be executed, sources simply configuration
no content yet
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.
Three stages: Script1, dependencies, Script3
no content yet
Focus on being small. Needs libowfat. Log support through pipe.
Scripts are slow. Startup time. Execution time. Unecessary overhead.
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.
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.
Systems without dependencies may result in a chaos state after booting up.
The dependencies are used, but because of soft dependencies, services may be started although their dependency is missing.
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.
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.
no content yet