|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
It also can be used as a utility to change the current runlevel of the system.
Most linux distributions are compatible with System V, but some distributions, such as Arch and Slackware, use a BSD-style and others, such as Gentoo, have their own customized version. Ubuntu distros now use upstart as a replacement for the traditional Init process.
The runlevels in System V describe certain states of a machine, characterized by the processes run. There are generally 8 runlevels. These are the runlevels 0 to 6 and S or s, which are aliased to the same runlevel. Of these eight, 3 are so-called "reserved" runlevels:
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).
| OS | Default runlevel |
|---|---|
| AIX | 2 |
| Arch Linux | 3 |
| Cent OS | 3 |
| Debian | 2 [5] |
| Gentoo Linux | 3 |
| Mandriva Linux | 5 |
| Mac OS X | 3 |
| Red Hat Linux / Fedora Core | 3 or 5 |
| Slackware Linux | 3 |
| Solaris | 3 [6] |
| SUSE Linux | 5 [7] |
| Ubuntu (Server and Desktop) | 2 [5] |
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:
$ runlevel $
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.
In Linux systems, with most modern
bootloaders (such as
LILO or
GRUB),
users can change which process the kernel spawns at the end of its initialization
from the normal default of /sbin/init. This is generally done by typing
init=/foo/bar
at 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.