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) 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 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 /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

STANDARDS CONFORMANCE

init: SVID2

Hewlett-Packard Company — HP-UX Release 9.0: August 1992

Museum

Related Articles