init(1M)init(1M)NAMEinit - process control initialization
SYNOPSISDESCRIPTION
The daemon and command is a general process spawner. Its primary role
is to create processes from a script stored in the file (see init‐
tab(4)). This file usually has spawn a on each line where users can
log in. It also controls autonomous processes required by any particu‐
lar system.
At boot time, is started as a system daemon.
While the system is running, a user-spawned directs the actions of the
boot It accepts a one-character argument and signals the boot with the
system call to perform the appropriate action.
The arguments have the following effect:
Place the system in one of the run levels
through
Process the
entries that have the special "run level" or without
changing the numeric run level.
Re-examine the
entries without changing the run level.
Enter the single-user environment.
When this level change occurs, the logical system con‐
sole is changed to the terminal from which the command
was executed.
Boot considers the system to be in a 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 for each of these run levels are defined in
the file. Boot can be in one of eight run levels, and or The run level
is changed by having a privileged user run the command. This user-
spawned sends appropriate signals to the boot
Boot is invoked inside the HP-UX system as the last step in the boot
procedure. Boot first performs any required machine-dependent initial‐
ization, such as setting the system context. Next, boot looks for the
file to see if there is an entry of the type (see inittab(4)). If an
entry is found, boot uses the run level specified in that entry as the
initial run level to enter. If this entry is not in or is not found,
boot requests that the user enter a run level from the logical system
console, If or is entered, boot goes into the level. This is the only
run level that does not require the existence of a properly formatted
file. If does not exist, then by default the only legal run level that
boot can enter is the single-user level.
In the single-user level, the logical system console terminal is opened
for reading and writing, and the command or 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 reprompts
for a new run level.
· User can signal boot and force it to change the current system
run level.
When attempting to boot the system, some processes spawned by boot may
send display messages to the system console (depending on the contents
of If messages are expected but do not appear during booting, it may be
caused by the logical system console being linked to a device that is
not the physical system console If this occurs, you can force boot to
relink to by pressing the DEL (delete) key (ASCII 127) on the physical
system console.
When boot prompts for the new run level, you can only enter one of the
digits through or the letter or If you enter boot operates as previ‐
ously described in single-user mode with the additional result that is
linked to the user's terminal line, thus making it the logical system
console. A message is generated on the physical system console, iden‐
tifying the new logical system console.
When boot 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, to those modes saved in the file This file
is written by boot whenever single-user mode is entered. If this file
does not exist when boot wants to read it, a warning is printed and
default settings are assumed.
If through is entered, boot enters the corresponding run level. Any
other input is rejected and a new prompt is issued. If this is the
first time boot has entered a run level other than single-user, boot
first scans for special entries of the type and These entries are per‐
formed — provided that the run level entered matches that of the entry
— before any normal processing of takes place. In this way, any spe‐
cial initialization of the operating system, such as mounting file sys‐
tems, can take place before users are allowed onto the system. The
file is scanned to find all entries that are to be processed for that
run level.
Run levels in HP-UX are defined as follows:
Shut down HP-UX.
Use for system administration (also known as "single-user
state"). When booting
into run level at powerup, the only access to the sys‐
tem is through a shell spawned at the system console
as the root user. The only processes running on the
system will be kernel daemons started directly by the
HP-UX kernel, daemon processes started from entries of
type in the shell on the system console, and any pro‐
cesses started by the system administrator. Adminis‐
tration operations that require the system to be in a
quiescent state (such as the fsck(1M) operation to
repair a file system) should be run in this state.
Transitioning into run level from a higher run level
does not terminate other system activity and does not
result in a "single-user state"; this operation should
not be done.
Start a subset of essential system processes. This state can
also be used to perform system administration tasks.
Start most system daemons and login processes. This state is
often
called the "multi-user state". Login processes either
at local terminals or over the network are possible.
Export filesystems and start other system processes. In this
state
NFS filesystems are often exported, as may be required
for an NFS server.
Activate graphical presentation managers and start other system
processes.
These states are available for user-defined operations.
The default run level is usually run level or depending on the system
configuration.
When transitions into a new run level the master sequencer script is
invoked. in turn invokes each of the start or kill scripts for each
installed subsystem for each intervening run level. When transitioning
to a higher run level start scripts are invoked, and when transitioning
to a lower run level kill scripts are invoked. See rc(1M).
In a multiuser environment, the file is usually set up so that boot
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 hang‐
ing up. When boot receives a child death signal telling it that a
process it spawned has died, it records the fact and the reason it died
in the database, and if it exist (see who(1)). A history of the pro‐
cesses spawned is kept in and if it exists.
To spawn each process in the file, boot 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 file, boot waits for one
of its descendant processes to die, a powerfail signal, or until it is
signaled by a user to change the system's run level. When one of the
above three conditions occurs, boot re-examines the file. New entries
can be added to the file at any time. However, boot still waits for
one of the above three conditions to occur. For an instantaneous
response, use the (or command to wake up boot to re-examine the file
without changing the run level.
If boot receives a powerfail signal and is not in single-user mode, it
scans for special entries. These entries are invoked (if the run lev‐
els permit) before any other processing takes place by boot In this
way, boot can perform various cleanup and recording functions whenever
the operating system experiences a power failure. Note, however, that
although boot receives immediately after a power failure, boot cannot
handle the signal until it resumes execution. Since execution order is
based on scheduling priority, any eligible process with a higher prior‐
ity executes before boot can scan and perform the specified functions.
When boot is requested to change run levels via a user it sends the
warning signal to all processes that are undefined in the target run
level. Boot waits 20 seconds before forcibly terminating these pro‐
cesses with the kill signal Note that boot assumes that all these pro‐
cesses (and their descendants) remain in the same process group that
boot originally created for them. If any process changes its process
group affiliation with either or (see setsid(2) and setpgid(2)), it
will not receive these signals. (Common examples of such processes are
the shells and (see csh(1) and ksh(1).) Such processes need to be ter‐
minated separately.
A user can be invoked only by users with appropriate privileges.
SECURITY FEATURES
Boot Authentication
The system administrator can enable the boot authentication feature.
If enabled, the system cannot be booted into single user mode until the
password of a user authorized to boot the system in single user mode is
provided. Refer to the file in the security(4) manual page for
detailed information on configurable parameters that affect the behav‐
ior of this command. The currently supported parameters for boot
authentication are:
and
On systems that have been converted to trusted mode, use the System
Administration Manager (SAM) program (see sam(1M)).
DIAGNOSTICS
If boot finds that it is continuously respawning an entry from 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 This prevents boot from using up sys‐
tem resources if there is a typographical error in the file or a pro‐
gram is removed that is referenced in
WARNINGS
Boot assumes that processes and descendants of processes spawned by
boot remain in the same process group that boot originally created for
them. When changing init states, special care should be taken with
processes that change their process group affiliation, such as and
One particular scenario that often causes confusing behavior can occur
when a child or is started by a login shell. When boot is asked to
change to a run level that would cause the original login shell to be
killed, the shell's descendant or 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
cannot kill this or process (or any of its children).
If a process is later started on the same tty as this previous shell,
the result may be two processes (the and the job control shell) compet‐
ing 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 is invoked from the lowest level (login)
shell when changing to an init state that may cause your login shell to
be killed.
If is unable to write to a message is logged to the console. This may
lead to the corruption of console settings.
HP-UX 11i Version 3 is the last release to support trusted systems
functionality.
FILESSEE ALSOcsh(1), ksh(1), login(1), sh(1), who(1), getty(1M), rc(1M), utmpd(1M),
ioctl(2), kill(2), setpgid(2), setsid(2), getutsent(3C), updateb‐
wdb(3C), inittab(4), security(4), utmp(4).
STANDARDS CONFORMANCEinit(1M)
