HP-UX Reference (11i v1 05/09) - 1M System Administration Commands A-M (vol 3)
i
init(1M) init(1M)
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 levels in HP-UX are defined as follows:
0 Shut down HP-UX.
Ss Use for system administration (also known as "single-user state"). When booting into run
level S 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 processes started from entries of type
sysinit in /etc/inittab , the shell on the system console, and any processes started
by the system administrator. 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
S from a higher run level does not terminate other sys-
tem activity and does not result in a "single-user state"; this operation should not be done.
1 Start a subset of essential system processes. This state can also be used to perform system
administration tasks.
2 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.
3 Export filesystems and start other system processes. In this state NFS filesystems are often
exported, as may be required for an NFS server.
4 Activate graphical presentation managers and start other system processes.
5−6 These states are available for user-defined operations.
The default run level is usually run level 3 or 4, depending on the system configuration.
When init transitions into a new run level 0−6, the master sequencer script
rc is invoked. rc 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
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 pro-
cess 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 process-
ing 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.
Section 1M−−360 Hewlett-Packard Company − 2 − HP-UX 11i Version 1: September 2005