init(1M) init(1M)
NAME
init - process control initialization
SYNOPSIS
DESCRIPTION
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 partic-
ular 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 console 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 ini-
tialization, 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:
o If the shell is terminated with an end-of-file, boot reprompts for a new run level.
o 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 con-
tents 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 sys-
tem console. A message is generated on the physical system console, identifying 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
special initialization of the operating system, such as mounting file systems, 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 system 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 pro-
cesses started from entries of type in the shell on the system console, and any processes started by the system adminis-
trator. Administration 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 termi-
nate 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 transi-
tioning 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
hanging 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 processes 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 instanta-
neous 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
levels permit) before any other processing takes place by boot In this way, boot can perform various cleanup and recording functions when-
ever 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 priority 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 processes 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 terminated 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 behavior 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 system resources if there is a typographical error in the file or a
program 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) com-
peting 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.
FILES
SEE ALSO
csh(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 CONFORMANCE
init(1M)