HP-UX Reference (11i v3 07/02) - 1M System Administration Commands A-M (vol 3)

i
init(1M) init(1M)
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 ter-
minating 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) pro-
gram (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 sys-
tem 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
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 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.
HP-UX 11i Version 3 is the last release to support trusted systems functionality.
FILES
/dev/syscon
/dev/systty
/etc/default/security
/etc/inittab
/etc/ioctl.syscon
/etc/utmp
/var/adm/wtmp
/var/adm/wtmps
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), updatebwdb(3C), inittab(4), security(4), utmp(4).
HP-UX 11i Version 3: February 2007 − 3 − Hewlett-Packard Company 343