The functionality diverged, in Unixes such as System III and System V, from the functionality provided by the init in Research Unix and its BSD derivatives. The usage on most Linux distributions is compatible with System V, but some distributions, such as Arch Linux and Slackware, use a BSD-style and others, such as Gentoo Linux, have their own customized version.
Advantages: Simple and easy to edit manually.
Problems: If a 3rd-party package needs to have an initialization script run during the boot procedure, it needs to edit one of the existing boot scripts, but a simple mistake in that process could lead to an unbootable system.
Note that modern *BSD variants have long supported a site-specific 'rc.local' file that is run in a sub-shell near the end of the boot sequence to mitigate the risks of making the system unbootable, and later, a local 'rc.d' directory where packages could install their own independent start/stop scripts (usually provided by the ports collection/pkgsrc). FreeBSD and NetBSD now use by default (as of version 5.0 and 1.5, respectively) the rc.d framework where the whole userland boot sequence is fragmented into smaller scripts, similarly to SysV. rcorder is used to determine in which order scripts are run, based on dependency information contained in the rc.d scripts.
Advantages: Flexibility and scalability.
Aside from runlevels 0, 1, and 6, every Unix and Unix-like system treats runlevels a little differently. The common denominator is the /etc/inittab file, which defines what each runlevel does (if they do anything at all).
|Red Hat Linux / Fedora Core||3 or 5|
|SUSE Linux||5 (Page 377)|
|Ubuntu (Server and Desktop)||2|
On the two Linux distributions defaulting to runlevel 5 in the table above, runlevel 5 is a multiuser graphical environment running the X Window System, usually with a display manager. However, in the Solaris operating system, runlevel 5 is typically reserved to shut down and automatically power off the machine.
On most systems users can check the current runlevel with either of the following commands:
$ who -r
The current runlevel is typically changed by root running the telinit or init commands. The default runlevel is set in the /etc/inittab file with the :initdefault: entry.
/sbin/init. This is generally done by typing
init=/foo/barat the bootloader's prompt. Appending
init=/bin/bash, for example, will bring up a single root shell, without a password.
For BSD variants, on most platforms, the bootstrap program can be interrupted and given the
boot -s command to boot into single-user mode. Single-user mode does not technically skip init; it still executes
/sbin/init, but it will make init ask for the path to a program to
exec() (the default being
/bin/sh) instead of doing the regular multi-user boot sequence. If the tty the kernel was booted from was marked as "insecure" in the
/etc/ttys file (on some systems, the current "securelevel" might also matter), init will first ask for the root password before allowing this (or fallback to multi-user mode if the user hits
CTRL+D). If this program is exited, the kernel will restart init in multi-user mode. The same things will happen if the system is switched from multi-user to single-mode while running. If init cannot be started after the kernel booted, it will panic and the system will be unusable. Changing the path to init itself is done differently on different variants (
boot -a on NetBSD, the
init_path loader variable on FreeBSD).
Various efforts have been made to replace the traditional init daemons with something better. Below is a list of these alternatives in no particular order.
The following list are links to projects that are not (yet) in widespread use.