NAME
init
—
process control
initialization
SYNOPSIS
init |
[-s ] |
DESCRIPTION
Theinit
program is the last stage of the boot process.
It normally begins multi-user operation.
init
is executed automatically by the
kernel, after the kernel has initialised all devices and mounted the root
file system. The kernel may try multiple possible paths for
init
, including /sbin/init,
/sbin/oinit, /sbin/init.bak,
and /rescue/init.
The following table describes the state machine used by
init
:
- Single user shell. If the kernel is booted in single user mode (see
boothowto(9)), then the kernel will pass the
-s
option toinit
to prevent the system from going multi-user and to instead execute a single user shell without starting the normal daemons. If the kernel is in a secure mode,init
will downgrade it to securelevel 0 (insecure mode). The system is then quiescent for maintenance work and may later be made to go to state 2 (multi-user) by exiting the single-user shell (with ^D). - Multi-user boot (default operation). Executes
/etc/rc (see
rc(8)). If this was the first state entered (as opposed to entering
here after state 1), then /etc/rc will be invoked
with its first argument being ‘autoboot’. If
/etc/rc exits with a non-zero (error) exit code,
commence single user operation by giving the super-user a shell on the
console by going to state 1 (single user). Otherwise, proceed to state 3.
If value of the “init.root” sysctl node is not equal to / at this point, the /etc/rc process will be run inside a chroot(2) indicated by sysctl with the same error handling as above.
If the administrator has not set the security level to -1 to indicate that the kernel should not run multiuser in secure mode, and the /etc/rc script has not set a higher level of security than level 1, then
init
will put the kernel into securelevel mode 1. See rc.conf(5) and secmodel_securelevel(9) for more information. - Set up ttys as specified in ttys(5). See below for more information. On completion, continue to state 4. If we did chroot in state 2, each getty(8) process will be run in the same chroot(2) path as in 2 (that is, the value of “init.root” sysctl is not re-read).
- Multi-user operation. Depending upon the signal received, change state
appropriately; on
SIGTERM
, go to state 7; onSIGHUP
, go to state 5; onSIGTSTP
, go to state 6. - Clean-up mode; re-read ttys(5), killing off the controlling processes on lines that are now ‘off’, and starting processes that are newly ‘on’. On completion, go to state 4.
- ‘Boring’ mode; no new sessions. Signals as per state 4.
- Shutdown mode. Send
SIGHUP
to all controlling processes, reap the processes for 30 seconds, and then go to state 1 (single user); warning if not all the processes died.
If the ‘console’ entry in the
ttys(5) file is marked “insecure”, then
init
will require that the superuser password be
entered before the system will start a single-user shell. The password check
is skipped if the ‘console’ is marked as
“secure”.
It should be noted that while init
has the
ability to start multi-user operation inside a
chroot(2) environment, the init
process
itself will always run in the “original root directory”. This
also implies that single-user mode is always started in the original root,
giving the possibility to create multi-user sessions in different root
directories over time. The “init.root” sysctl node is
fabricated by init
at startup and re-created any
time it is found to be missing. Type of the node is string capable of
holding full pathname, and is only accessible by the superuser (unless
explicitly destroyed and re-created with different specification).
In multi-user operation, init
maintains
processes for the terminal ports found in the file
ttys(5). init
reads this file, and executes
the command found in the second field. This command is usually
getty(8); it opens and initializes the tty line and executes the
login(1) program. The
login(1) program, when a valid user logs in, executes a shell for
that user. When this shell dies, either because the user logged out or an
abnormal termination occurred (a signal), the init
program wakes up, deletes the user from the
utmp(5) and
utmpx(5) files of current users and records the logout in the
wtmp(5) and
wtmpx(5) files. The cycle is then restarted by
init
executing a new
getty(8) for the line.
Line status (on, off, secure, getty, or window information) may be
changed in the ttys(5) file without a reboot by sending the signal
SIGHUP
to init
with the
command “kill -s HUP 1
”. This is
referenced in the table above as state 5. On receipt of this signal,
init
re-reads the
ttys(5) file. When a line is turned off in
ttys(5), init
will send a
SIGHUP
signal to the controlling process for the
session associated with the line. For any lines that were previously turned
off in the ttys(5) file and are now on, init
executes a
new getty(8) to enable a new login. If the getty or window field for a
line is changed, the change takes effect at the end of the current login
session (e.g., the next time init
starts a process
on the line). If a line is commented out or deleted from
ttys(5), init
will not do anything at all to
that line. However, it will complain that the relationship between lines in
the ttys(5) file and records in the
utmp(5) file is out of sync, so this practice is not recommended.
init
will terminate multi-user operations
and resume single-user mode if sent a terminate
(TERM
) signal, for example,
“kill -s TERM 1
”. If there are
processes outstanding that are deadlocked (because of hardware or software
failure), init
will not wait for them all to die
(which might take forever), but will time out after 30 seconds and print a
warning message.
init
will cease creating new
getty(8)'s and allow the system to slowly die away, if it is sent a
terminal stop (TSTP
) signal, i.e.,
“kill -s TSTP 1
”. A later hangup will
resume full multi-user operations, or a terminate will start a single user
shell. This hook is used by
reboot(8) and
halt(8).
The role of init
is so critical that if it
dies, the system will reboot itself automatically. If, at bootstrap time,
the init
process cannot be located, or exits during
its initialisation, the system will panic with the message “panic:
init died (signal %d, exit %d)”.
If /dev/console does not exist,
init
will cd to /dev and run
“MAKEDEV -MM init
”.
MAKEDEV(8) will use
mount_tmpfs(8) or
mount_mfs(8) to create a memory file system mounted over
/dev that contains the standard devices considered
necessary to boot the system.
FILES
- /dev/console
- System console device.
- /dev/tty*
- Terminal ports found in ttys(5).
- /var/run/utmp{,x}
- Record of current users on the system.
- /var/log/wtmp{,x}
- Record of all logins and logouts.
- /etc/ttys
- The terminal initialization information file.
- /etc/rc
- System startup commands.
DIAGNOSTICS
- getty repeating too quickly on port %s, sleeping
- A process being started to service a line is exiting quickly each time it is started. This is often caused by a ringing or noisy terminal line. Init will sleep for 10 seconds, then continue trying to start the process.
- some processes would not die; ps axl advised.
- A process is hung and could not be killed when the system was shutting down. This condition is usually caused by a process that is stuck in a device driver because of a persistent device error condition.
SEE ALSO
config(1), kill(1), login(1), sh(1), options(4), ttys(5), getty(8), halt(8), MAKEDEV(8), MAKEDEV.local(8), mount_mfs(8), mount_tmpfs(8), rc(8), reboot(8), rescue(8), shutdown(8), sysctl(8), secmodel_bsd44(9), secmodel_securelevel(9)
HISTORY
An init
command appeared in
Version 1 AT&T UNIX.