init(1M) init(1M)
NAME [Toc] [Back]
init - process control initialization
SYNOPSIS [Toc] [Back]
/sbin/init [0|1|2|3|4|5|6|S|s|Q|q|a|b|c]
DESCRIPTION [Toc] [Back]
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 machinedependent
initialization, such as setting the system context. 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
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: August 2003
init(1M) init(1M)
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
Hewlett-Packard Company - 2 - HP-UX 11i Version 2: August 2003
init(1M) init(1M)
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.
S|s Use for system administration (also known as "singleuser
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 system 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,
Hewlett-Packard Company - 3 - HP-UX 11i Version 2: August 2003
init(1M) init(1M)
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 process it spawned has died, it records the fact and the reason
it died in the utmps database, /etc/utmp, /var/adm/wtmps, and
/var/adm/wtmp if it exist (see who(1)). A history of the processes
spawned is kept in /var/adm/wtmps and /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 setsi
), 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.
Hewlett-Packard Company - 4 - HP-UX 11i Version 2: August 2003
init(1M) init(1M)
A user init can be invoked only by users with appropriate privileges.
SECURITY FEATURES [Toc] [Back]
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 /etc/default/security 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:
BOOT_AUTH and BOOT_USERS
On systems that have been converted to trusted mode, use the System
Administration Manager (SAM) program (see sam(1M)).
DIAGNOSTICS [Toc] [Back]
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 using up system resources if there is a
typographical error in the inittab file or a program is removed that
is referenced in inittab.
WARNINGS [Toc] [Back]
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
Hewlett-Packard Company - 5 - HP-UX 11i Version 2: August 2003
init(1M) init(1M)
cause your login shell to be killed.
If init is unable to write to /etc/ioctl.syscon, a message is logged
to the console. This may lead to the corruption of console settings.
FILES [Toc] [Back]
/dev/syscon
/dev/systty
/etc/default/security
/etc/inittab
/etc/ioctl.syscon
/etc/utmp
/var/adm/wtmp
/var/adm/wtmps
SEE ALSO [Toc] [Back]
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),
updatebwdb(3C), inittab(4), security(4), utmp(4).
STANDARDS CONFORMANCE [Toc] [Back]
init: SVID2, SVID3
Hewlett-Packard Company - 6 - HP-UX 11i Version 2: August 2003 [ Back ] |
