HPUX init[1m]
init(1M) init(1M)
NAME
init, telinit - process control initialization
SYNOPSIS
/etc/init [0123456SsQq]
/etc/telinit [0123456sSQqabc]
DESCRIPTION
init
init 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 gettys on each line
that users can log in on. It also controls autonomous processes
required by any particular system.
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 init for each of these run levels is
defined in the inittab file. 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 /etc/init (which is linked to /etc/telinit). This user-spawned
init sends appropriate signals to the original init spawned by the
operating system when the system was rebooted, telling it which run
level to change to.
init is invoked inside the HP-UX system as the last step in the boot
procedure. init first performs any required machine-dependent
initialization, such as setting the system context (see context(5)).
Next init looks for file /etc/inittab to see if there is an entry of
the type initdefault (see inittab(4)). If an initdefault entry is
found, init uses the run level specified in that entry as the initial
run level to enter. If this entry is not in inittab or inittab is not
found, init requests that the user enter a run level from the logical
system console, /dev/syscon. If an S (s) is entered, 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
/etc/inittab does not exist, then by default the only legal run level
that 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 /bin/su is invoked immediately.
To exit from the single-user run level, one of two options can be
elected: First, if the shell is terminated (via an end-of-file), init
reprompts for a new run level. Second, the init or telinit command
can signal init and force it to change the current system run level.
When attempting to boot the system, some processes spawned by 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)
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
init(1M) init(1M)
being linked to a device that is not the physical system console
(/dev/systty). If this occurs, init can be forced to relink
/dev/syscon to /dev/systty by typing a delete on the physical system
console.
When init prompts for the new run level, the operator can enter only
one of the digits 0 through 6 or the letter S or s. If S is entered
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 init comes up initially, and whenever it switches out of single-
user state to normal run states, it sets the ioctl(2) states of the
logical system console, /dev/syscon, to those modes saved in the file
/etc/ioctl.syscon. This file is written by init whenever single-user
mode is entered. If this file does not exist when init wants to read
it, a warning is printed and default settings are assumed.
If a 0 through 6 is entered init enters the corresponding run level.
Any other input is rejected and a new prompt is issued. If this is
the first time init has entered a run level other than single-user,
init first scans inittab for special entries of the type boot and
bootwait. These entries are performed, providing 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 level 2 is usually defined by the user to contain all of the
terminal processes and daemons that are spawned in the multi-user
environment.
In a multi-user environment, the inittab file is usually set up so
that 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 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 /etc/utmp and /etc/wtmp if it exists (see who(1)). A history
of the processes spawned is kept in /etc/wtmp if such a file exists.
To spawn each process in the inittab file, init reads each entry and,
for each entry which should be respawned, it forks a child process.
After it has spawned all of the processes specified by the inittab
file, init waits for one of its descendant processes to die, a
powerfail signal, or until init is signaled by init or telinit to
change the system's run level . When one of the above three conditions
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August 1992
init(1M) init(1M)
occurs, init re-examines the inittab file. New entries can be added
to the inittab file at any time. However, init still waits for one of
the above three conditions to occur. To provide for an instantaneous
response, the init Q or init q command can wake init to re-examine the
inittab file.
If 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 processing takes
place by init. In this way init can perform various cleanup and
recording functions whenever the operating system experiences a power
failure. Note, however, that although init receives (SIGPWR)
immediately after a power failure, 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
init can scan inittab and perform the specified functions.
When init is requested to change run levels (via telinit), init sends
the warning signal (SIGTERM) to all processes that are undefined in
the target run level. init waits 20 seconds before forcibly
terminating these processes via the kill signal (SIGKILL). Note that
init assumes that all these processes (and their descendants) remain
in the same process group init originally created for them. If any
process changes its process group affiliation via either setpgrp(2) or
setpgrp2(2), it will not receive these signals. (Common examples of
such a process are ksh(1) and csh(1)). Such processes need to be
terminated separately.
telinit
telinit, which is linked to /etc/init, is used to direct the actions
of init. It takes a one-character argument and signals init via the
kill system call to perform the appropriate action. The following
arguments serve as directives to init:
0-6 tells init to place the system in one of the run levels
0 through 6.
a, b, c tells init to process only those /etc/inittab file
entries having run level a, b, or c set.
Q or q tells init to re-examine the /etc/inittab file.
S or s tells init to enter the single user environment. When
this level change is effected, logical system console
/dev/syscon is changed to the terminal from which the
command was executed.
telinit can be invoked only by users with appropriate privileges.
DIAGNOSTICS
If init finds that it is continuously respawning an entry from
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August 1992
init(1M) init(1M)
/etc/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 has elapsed or it receives a signal from a user init
(telinit). This prevents init from eating up system resources when
someone makes a typographical error in the inittab file or a program
is removed that is referenced in the inittab.
WARNINGS
init assumes that processes and descendants of processes spawned by
init remain in the same process group that init originally created for
them. When changing init states, special care should be taken with
processes that change their process group affiliation (ksh(1) and
csh(1) for example).
One particular scenario that often causes confusing behavior can occur
when a child ksh or csh are started by a login shell. When init is
asked to change to a run level that would cause the original login
shell to be killed, the shell's descendant ksh or csh process does not
recieve a hangup signal since it has changed its process group
affiliation and is no longer affiliated with the process group of the
original shell. init cannot kill this ksh or csh process (or any of
its children).
If a getty(1M) process is later started on the same tty as this
previous shell, the result may be two processes (the getty and 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 init or telinit is invoked from the
lowest level (login) shell when changing to an init state that may
cause your login shell to be killed.
FILES
/etc/clusterconf
/etc/inittab
/etc/ioctl.syscon
/dev/syscon
/dev/systty
/etc/utmp
/etc/wtmp
SEE ALSO
getty(1M), login(1), sh(1), who(1), kill(2), clusterconf(4),
inittab(4), utmp(4), context(5).
STANDARDS CONFORMANCE
init: SVID2
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992