HP-UX Reference (11i v1 00/12) - 1M System Administration Commands A-M (vol 3)
__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man1m/!!!intro.1m
________________________________________________________________
___ ___
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.
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.
FILES
/dev/syscon
/dev/systty
/etc/default/security
/etc/inittab
/etc/ioctl.syscon
/etc/utmp
/var/adm/wtmp
SEE ALSO
csh(1), ksh(1), login(1), sh(1), who(1), getty(1M), rc(1M), ioctl(2), kill(2), setpgid(2), setsid(2), inittab(4), secu-
rity(4), utmp(4).
STANDARDS CONFORMANCE
init: SVID2, SVID3
Section 1M−−350 − 3 − HP-UX Release 11i: December 2000
___
___