init(1M) init(1M) NAME init, telinit - process control initialization SYNOPSIS /etc/init [0123456SsQqabc] /etc/telinit [0123456SsQqabc] DESCRIPTION init init is a general process spawner. Its primary role is to create processes from information stored in an inittab file (see inittab(4)). The default inittab file used is /etc/inittab; other files can be specified using the INITTAB keyword in the system file (see system(4)). At any given time, the system is in one of eight possible run levels. A run level is a software configuration of the system under which only a selected group of processes exist. The processes spawned by init for each of these run levels is defined in inittab. init can be in one of eight run levels, 0-6 and S or s (run levels S and s are identical). The run level changes when a privileged user runs /etc/init. This user-level init sends appropriate signals to the original init (the one spawned by the operating system when the system was booted) designating the run level to which the latter should change. The following are the arguments to init. 0 Shut the machine down so it is safe to remove the power. If it can, the machine will remove the power provided the kernel power removal flag was previously set (as by the command /sbin/uadmin 256 9). 1 Put the system into system administrator mode. All filesystems are mounted. Only a small set of essential kernel processes run. This mode is for administrative tasks such as installing optional utilities packages. All files are accessible and no users are logged in on the system. 2 Put the system into multi-user state. All multi-user environment terminal processes and daemons are spawned. 3 Start the remote file sharing processes and daemons. Mount and advertise remote resources. Run level 3 extends multi-user mode and is known as the remote-file-sharing state. 4 Define a configuration for an alternative multi-user environment. This state is not necessary for normal system operations; it is usually not used. 5 Stop the IRIX system and enter firmware mode. 6 Stop the IRIX system and reboot to the state defined by the initdefault entry in inittab. a,b,c Process only those inittab entries for which the run level is set to a, b, or c. These are pseudo-states that can be defined to run certain commands but do not cause the current run level to change. Q,q Re-examine inittab. S,s Enter single-user mode. When the system changes to this state as the result of a command, the terminal from which the command was executed becomes the system console. This is the only run level that doesn't require the existence of a properly formatted inittab file. If this file does not exist, then by default the only legal run level that init can enter is the single-user mode. The set of filesystems mounted and the list of processes killed when a system enters system state s are not always the same; which filesystems are mounted and which processes are killed depends on the method used for putting the system into state s and the rules in force at your computer site. The following paragraphs describe state s in three circumstances: when the system is brought up to s with init; when the system is brought down (from another state) to s with init; and when the system is brought down to s with shutdown. When the system is brought up to s with init, the only filesystem mounted is / (root). Filesystems for users' files are not mounted. With the commands available on the mounted filesystems, you can manipulate the filesystems or transition to other system states. Only essential kernel processes are kept running. When the system is brought down to s with init, all mounted filesystems remain mounted and all processes started by init that should be running only in multi-user mode are killed. Because all login related processes are killed, users cannot access the system while it's in this state. In addition, any process for which the utmp file has an entry is killed. Other processes not started directly by init (such as cron) remain running. When you change to s with shutdown, the system is restored to the state in which it was running when you first booted the machine and came up in single-user state, as described above. (The powerdown(1M) command takes the system through state s on the way to turning off the machine; thus you can't use this command to put the system in system state s.) When an IRIX system is booted, init is invoked and the following occurs. First, init looks in inittab for the initdefault entry (see inittab(4)). If there is one, init usually uses the run level specified in that entry as the initial run level for the system. If there is no initdefault entry in inittab, init requests that the user enter a run level from the virtual system console. If an S or s is entered, init takes the system to single-user state. In the single-user state the virtual console terminal is assigned to the user's terminal and is opened for reading and writing. The command /sbin/sulogin is invoked, which prompts the user for a root password (see sulogin(1M)), and a message is generated on the physical console saying where the virtual console has been relocated. If /bin/sulogin cannot be found, then init attempts to launch a shell: looking first for /bin/csh, then for /sbin/sh, then finally for /bin/ksh. Use either init or telinit to signal init to change the run level of the system. Note that if the shell is terminated (via an end-of-file), init only re-initializes to the single-user state if the inittab file does not exist. If a 0 through 6 is entered, init enters the corresponding run level. Run levels 0, 5, and 6 are reserved states for shutting the system down. Run levels 2, 3, and 4 are available as multi-user operating states. If this is the first time since power up that init has entered a run level other than single-user state, init first scans inittab for boot and bootwait entries (see inittab(4)). These entries are performed before any other processing of inittab takes place, providing that the run level entered matches that of the entry. In this way any special initialization of the operating system, such as mounting filesystems, can take place before users are allowed onto the system. init then scans inittab and executes all other entries that are to be processed for that run level. To spawn each process in inittab, init reads each entry and for each entry that should be respawned, it forks a child process. After it has spawned all of the processes specified by inittab, init waits for one of its descendant processes to die, a powerfail signal, or a signal from another init or telinit process to change the system's run level. When one of these conditions occurs, init re-examines inittab. New entries can be added to inittab at any time; however, init still waits for one of the above three conditions to occur before re-examining inittab. To get around this, the init Q (or init q) command wakes init to re-examine inittab immediately. Note, however, that if the inittab has been edited to change baud-rates, those changes only take effect when new getty processes are spawned to oversee those ports. Use killall getty to terminate all current getty processes, then init Q to re-examine the inittab and respawn them all again with the new baud-rates. When init comes up at boot time and whenever the system changes from the single-user state to another run state, init sets the ioctl(2) states of the virtual console to those modes saved in the file /etc/ioctl.syscon. This file is written by init whenever the single-user state is entered. When a run level change request is made init sends the warning signal (SIGTERM) to all processes that are undefined in the target run level. init waits five seconds before forcibly terminating these processes via the kill signal (SIGKILL). When init receives a signal telling it that a process it spawned has died, it records the fact and the reason it died in /var/adm/utmp and /var/adm/wtmp if it exists (see who(1)). A history of the processes spawned is kept in /var/adm/wtmp. If init receives a powerfail signal (SIGPWR) it scans inittab for special entries of the type powerfail and powerwait. These entries are invoked (if the run levels permit) before any further processing takes place. In this way init can perform various cleanup and recording functions during the powerdown of the operating system. telinit telinit, which is linked to /sbin/init, is used to direct the actions of init. It takes a one-character argument and signals init to take the appropriate action. FILES /etc/inittab default inittab file /var/adm/utmp /var/adm/wtmp /etc/TIMEZONE /etc/ioctl.syscon /dev/console SEE ALSO getty(1M), killall(1M), login(1), powerdown(1M), sh(1), shutdown(1M), stty(1), sulogin(1M), uadmin(1M), who(1), kill(2), boot_cpuset(4), inittab(4), system(4), timezone(4), utmp(4), termio(7). DIAGNOSTICS If init finds that it is respawning an entry from the inittab file more than ten times in two minutes, it assumes that there is an error in the command string in the entry, and generates an error message on the system console. It then refuses to respawn this entry until either five minutes has elapsed or it receives a signal from a user-spawned init or telinit. This prevents init from consuming system resources when someone makes a typographical error in the inittab file or a program is removed that is referenced in inittab. When attempting to boot the system, failure of init to prompt for a new run level may be because the virtual system console is linked to a device other than the physical system console. NOTES init and telinit can be run only by a privileged user. The S or s state must not be used indiscriminately in the inittab file. A good rule to follow when modifying this file is to avoid adding this state to any line other than the initdefault. If a default state is not specified in the initdefault entry in inittab, state 6 is entered. Consequently, the system loops; that is, it goes to firmware and reboots continuously. If the utmp file cannot be created when booting the system, the system boots to state s regardless of the state specified in the initdefault entry in the inittab file. In the event of a file table overflow condition, init uses a file descriptor associated with the inittab file that it retained from the last time it accessed that file. This prevents init from going into single user mode when it cannot obtain a file descriptor to open the inittab file. The environment for init and all processes directly started by is set initially from a table that is builtin, and then by parsing the file /etc/TIMEZONE. Lines in that file that are too long are ignored. Page 5