HP-UX Reference (11i v2 03/08) - 1M System Administration Commands A-M (vol 3)

i
init(1M) init(1M)
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.
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
/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
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 sig-
nal from a user init. This prevents boot init from using up system resources if there is a typographi-
cal 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 origi-
nal 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.
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
/dev/syscon
/dev/systty
/etc/default/security
/etc/inittab
/etc/ioctl.syscon
/etc/utmp
/var/adm/wtmp
/var/adm/wtmps
HP-UX 11i Version 2: August 2003 − 3 − Hewlett-Packard Company Section 1M−−309