init(1M) init(1M)NAME init, telinit - process control initialization SYNOPSIS /etc/init [0123456SsQqabc] DESCRIPTION init is a general process spawner. Its primary role is to create processes based on the line entries in /etc/inittab (see inittab(4)). This file usually instructs init to spawn terminal listeners (see getty(1M)) on each serial line available for access to the system. It can also manage the system's autonomous processes, often called daemons. For interchangeable use, telinit is linked to init (see ln(1)). Normally, the permissions are set so that telinit and init can only be run by the superuser or a member of the group sys. Certain single-letter arguments for init are called run lev- els, and others are called directives. Run level can be a number between one and six or the letters s or S. init places the system in the specified run level. Using s or S causes init to change the virtual system teletype, /dev/syscon, to the terminal from which the command was executed, as well as to establish the corresponding run level. Directive can be a, b, c, Q, or q. The Q or q directive causes init to re-examine the /etc/inittab file and honor any changes that apply to the current run level. For exam- ple, a getty process that is changed from respawn to off in /etc/inittab will be killed when init q is en- tered. The a, b, or c directive causes init to create or remove only those processes with the corresponding letter in their run level field in /etc/inittab. Af- fected processes may be switched on or off as specified in the action field (see inittab(4)). A run level can be viewed as a software configuration that must, at minimum, consist of the processes specified in /etc/inittab for that run level. init can be in one of eight run levels, 0 through 6, S or s. Besides using init to change the run level, it can be used to help switch various processes on and off in tandem (see directives, previously described). April, 1990 1
init(1M) init(1M)An init process is run as part of A/UX initialization, and that copy of the program must run continuously. It main- tains the system state. By invoking the init program again, at the command line, the original copy of init can be in- structed to change the system's run level. The newly re- quested copy of init sends the appropriate signals to the one created at system startup. Following is a description of the role init plays in the startup process, and gives examples of the special process- ing init performs when there is a change in run level or in the status of a process (termination). First init looks for an entry in /etc/inittab in which init- default appears in the action field (see inittab(4)). If there is one, init uses the run level specified in that en- try 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 virtual system console, /dev/syscon. If an S (s) is entered, init goes into the single-user level. This is the only run level that doesn't require the existence of a properly formatted inittab file. If /etc/inittab doesn't exist, then, by default, the only legal run level that init can enter is the single-user lev- el. In the single-user level, the virtual console terminal /dev/syscon is opened for reading and writing and the com- mand /bin/su is invoked immediately. To exit from the single-user run level, one of two flag options can be elect- ed. First, if the shell is terminated (via an end-of-file), init reprompts for a new run level. Second, the init com- mand can signal init and force it to change the run level of the system. When attempting to boot the system, failure of init to prompt for a new run level may be due to the fact that the device /dev/syscon is linked to a device other than the phy- sical system teletype (/dev/systty). If this occurs, init can be forced to relink /dev/syscon by typing a delete on the system teletype which is co-located with the processor. When init prompts for the new run level, the operator may enter only one of the digits 0 through 6 or the letters 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 virtual system console. A message is generated on the phy- sical console, /dev/systty, saying where the virtual termi- nal has been relocated. 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 virtual console, /dev/syscon, to those modes 2 April, 1990
init(1M) init(1M)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 will be rejected and the user will be re-prompted. If this is the first time init has en- tered a run level other than single-user, init first scans inittab for special entries of the type boot and bootwait. These entries are performed, provided that the run level en- tered matches that of the entry before any normal processing of inittab takes place. In this way, any special initiali- zation of the operating system, such as mounting file sys- tems, can take place before users are allowed onto the sys- tem. 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 multiuser environment. In a multiuser environment, the inittab file is usually set up so that init will create a process for each terminal on the system. For terminal processes, the shell will ultimately terminate because an end-of-file was either typed explicitly or gen- erated as a result of hanging up. When init receives a child-death signal, reporting the death of a process it has spawned, it records the death and the cause of death in /etc/utmp, and in /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 forks a child process for each entry that should be respawned. After it has spawned all of the processes specified by the inittab file, init waits for one of its descendant processes to die, for a power-failure signal, or until it is signaled by init to change the system's run lev- el. When one of these 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 these conditions. To process the altered or new entries in /etc/inittab immediately, use the command init Q or init q to awaken init and make it re-examine the inittab file. If init receives a power-failure signal (SIGPWR) and is not in single-user mode, it scans inittab for special powerfail entries. These entries are invoked (if the run levels per- mit) before any further processing takes place. In this April, 1990 3
init(1M) init(1M)way, init can perform various cleanup and recording func- tions whenever the operating system experiences a power failure. When init is requested to change run levels, init sends the warning signal (SIGTERM) to all processes that are undefined in the target run level. init waits 20 seconds before for- cibly terminating these processes via the kill signal (SIG- KILL). When the q or Q flag option is specified init re- moves processes that are currently running but which are set to be off in /etc/inittab for the current run level. FILES /etc/init /etc/init /etc/inittab /etc/utmp /etc/wtmp /etc/ioctl.syscon /dev/syscon /dev/systty SEE ALSO getty(1M), login(1), sh(1), who(1), kill(2), inittab(4), ioctl.syscon(4), utmp(4). ``System Startup and Shutdown'' in A/UX Local System Ad- ministration. DIAGNOSTICS If init finds that it is continuously respawning an entry from /etc/inittab more than 10 times in 2 minutes, it as- sumes that there is an error in the command string and will generate an error message on the system console. init re- fuses to respawn this entry until either 5 minutes has elapsed or it receives a signal from a user init. This prevents init from monopolizing system resources when some- one makes a typographical error in inittab file or a program is removed that is referenced in inittab. 4 April, 1990