hpux 10.20 - init (1)
NAME
init - process control initialization
SYNOPSIS
/sbin/init [0|1|2|3|4|5|6|S|s|Q|q|a|b|c]
DESCRIPTION
The init daemon and command is a general process spawner. Its primary
role is to create processes from a script stored in the file
/etc/inittab (see inittab(4)). This file usually has init spawn a
getty on each line where users can log in. It also controls
autonomous processes required by any particular system.
At boot time, init is started as a system daemon.
While the system is running, a user-spawned init directs the actions
of the boot init. It accepts a one-character argument and signals the
boot init with the kill() system call to perform the appropriate
action.
The arguments have the following effect:
0-6 Place the system in one of the run levels 0 through 6.
a|b|c Process the inittab entries that have the special "run
level" a, b, or c, without changing the numeric run
level.
Q|q Re-examine the inittab entries without changing the run
level.
S|s Enter the single-user environment. When this level
change occurs, the logical system console /dev/syscon
is changed to the terminal from which the command was
executed.
Boot init considers the system to be in a run level at any given time.
A run level can be viewed as a software configuration of the system,
where each configuration allows only a selected group of processes to
exist. The processes spawned by boot init for each of these run
levels are defined in the inittab file. Boot init can be in one of
eight run levels, 0-6, and S or s. The run level is changed by having
a privileged user run the init command. This user-spawned init sends
appropriate signals to the boot init.
Boot init is invoked inside the HP-UX system as the last step in the
boot procedure. Boot init first performs any required machine-
dependent initialization, such as setting the system context (see
context(5)). Next, boot init looks for the inittab file to see if
there is an entry of the type initdefault (see inittab(4)). If an
initdefault entry is found, boot init uses the run level specified in
that entry as the initial run level to enter. If this entry is not in
inittab, or inittab is not found, boot init requests that the user
enter a run level from the logical system console, /dev/syscon. If S
or s is entered, boot init goes into the single-user level. This is
the only run level that does not require the existence of a properly
formatted inittab file. If inittab does not exist, then by default
the only legal run level that boot init can enter is the single-user
level.
In the single-user level, the logical system console terminal
/dev/syscon is opened for reading and writing, and the command
/usr/bin/su, /usr/bin/sh, or /sbin/sh is invoked immediately. To exit
from the single-user run level, one of two options can be selected:
+ If the shell is terminated with an end-of-file, boot init
reprompts for a new run level.
+ User init can signal boot init and force it to change the
current system run level.
When attempting to boot the system, some processes spawned by boot
init may send display messages to the system console (depending on the
contents of inittab). If messages are expected but do not appear
during booting, it may be caused by the logical system console
(/dev/syscon) being linked to a device that is not the physical system
console (/dev/systty). If this occurs, you can force boot init to
relink /dev/syscon to /dev/systty by pressing the DEL (delete) key
(ASCII 127) on the physical system console.
When boot init prompts for the new run level, you can only enter one
of the digits 0 through 6 or the letter S or s. If you enter S, boot
init operates as previously described in single-user mode with the
additional result that /dev/syscon is linked to the user's terminal
line, thus making it the logical system console. A message is
generated on the physical system console, /dev/systty, identifying the
new logical system console.
When boot init comes up initially, and whenever it switches out of
single-user state to normal run states, it sets the states (see
ioctl(2)) of the logical system console, /dev/syscon, to those modes
saved in the file /etc/ioctl.syscon. This file is written by boot
init whenever single-user mode is entered. If this file does not
exist when boot init wants to read it, a warning is printed and
default settings are assumed.
If 0 through 6 is entered, boot init enters the corresponding run
level. Any other input is rejected and a new prompt is issued. If
this is the first time boot init has entered a run level other than
single-user, boot init first scans inittab for special entries of the
type boot and bootwait. These entries are performed - provided that
the run level entered matches that of the entry - before any normal
processing of inittab takes place. In this way, any special
initialization of the operating system, such as mounting file systems,
can take place before users are allowed onto the system. The inittab
file is scanned to find all entries that are to be processed for that
run level.
Run level 2 is usually defined as the "normal" run level, containing
all of the terminal processes and daemons that are spawned in the
multiuser environment.
In a multiuser environment, the inittab file is usually set up so that
boot init creates a process for each terminal on the system.
For terminal processes, ultimately the shell terminates because of an
end-of-file either typed explicitly or generated as the result of
hanging up. When boot init receives a child death signal telling it
that a process it spawned has died, it records the fact and the reason
it died in /etc/utmp and /var/adm/wtmp, if they exist (see who(1)). A
history of the processes spawned is kept in /var/adm/wtmp, if it
exists.
To spawn each process in the inittab file, boot init reads each entry
and, for each entry that should be respawned, it forks a child
process. After it has spawned all of the processes specified by the
inittab file, boot init waits for one of its descendant processes to
die, a powerfail signal, or until it is signaled by a user init to
change the system's run level. When one of the above three conditions
occurs, boot init re-examines the inittab file. New entries can be
added to the inittab file at any time. However, boot init still waits
for one of the above three conditions to occur. For an instantaneous
response, use the init Q (or init q) command to wake up boot init to
re-examine the inittab file without changing the run level.
If boot init receives a powerfail signal (SIGPWR) and is not in
single-user mode, it scans inittab for special powerfail entries.
These entries are invoked (if the run levels permit) before any other
processing takes place by boot init. In this way, boot init can
perform various cleanup and recording functions whenever the operating
system experiences a power failure. Note, however, that although boot
init receives SIGPWR immediately after a power failure, boot init
cannot handle the signal until it resumes execution. Since execution
order is based on scheduling priority, any eligible process with a
higher priority executes before boot init can scan inittab and perform
the specified functions.
When boot init is requested to change run levels via a user init, it
sends the warning signal SIGTERM to all processes that are undefined
in the target run level. Boot init waits 20 seconds before forcibly
terminating these processes with the kill signal SIGKILL. Note that
boot init assumes that all these processes (and their descendants)
remain in the same process group that boot init originally created for
them. If any process changes its process group affiliation with
either setpgrp() or setpgrp2() (see setsid(2) and setpgid(2)), it will
not receive these signals. (Common examples of such processes are the
shells csh and ksh (see csh(1) and ksh(1).) Such processes need to be
terminated separately.
A user init can be invoked only by users with appropriate privileges.
DIAGNOSTICS
If boot init finds that it is continuously respawning an entry from
inittab more than 10 times in 2 minutes, it will assume that there is
an error in the command string, generate an error message on the
system console, and refuse to respawn this entry until either 5
minutes have elapsed or it receives a signal from a user init. This
prevents boot init from eating up system resources if there is a
typographical error in the inittab file or a program is removed that
is referenced in inittab.
WARNINGS
Boot init assumes that processes and descendants of processes spawned
by boot init remain in the same process group that boot init
originally created for them. When changing init states, special care
should be taken with processes that change their process group
affiliation, such as csh and ksh.
One particular scenario that often causes confusing behavior can occur
when a child csh or ksh is started by a login shell. When boot init
is asked to change to a run level that would cause the original login
shell to be killed, the shell's descendant csh or ksh process does not
receive a hangup signal since it has changed its process group
affiliation and is no longer affiliated with the process group of the
original shell. Boot init cannot kill this csh or ksh process (or any
of its children).
If a getty process is later started on the same tty as this previous
shell, the result may be two processes (the getty and the job control
shell) competing for input on the tty.
To avoid problems such as this, always be sure to manually kill any
job control shells that should not be running after changing init
states. Also, always be sure that user init is invoked from the
lowest level (login) shell when changing to an init state that may
cause your login shell to be killed.
FILES
/dev/syscon
/dev/systty
/etc/inittab
/etc/ioctl.syscon
/etc/utmp
/var/adm/wtmp
SEE ALSO
csh(1), ksh(1), login(1), sh(1), who(1), getty(1M), ioctl(2), kill(2),
setpgid(2), setsid(2), clusterconf(4), inittab(4), utmp(4),
context(5).
STANDARDS CONFORMANCE
init: SVID2, SVID3