/sbin/telinit [0123456SsQqabc]
At any given time, the system is in one of eight possible states. A system state 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 system states is defined in inittab. init can be in one of eight system states, and ``S'' or ``s'' (system states ``S'' and ``s'' are identical). The system state changes when a privileged user executes /sbin/init. This user-initiated init sends appropriate signals to the original init (the one spawned by the operating system when the system was booted) designating the system state to which the latter should change.
The following are the arguments to init.
This is the only system state that doesn't require the existence of a properly formatted inittab file. If this file does not exist, then by default the only legal system state that init can enter is the single-user state.
The set of file systems mounted and the list of processes killed when a system enters single-user state are not always the same; which file systems are mounted and which processes are killed depends on the method used for putting the system into single-user state and the rules in force at your computer site. The following paragraphs describe single-user state in three circumstances: when the system is brought up to s with init; when the system is brought (from another state) to single-user state with init; and when the system is brought to single-user state with shutdown.
When the system is brought up to single-user state with init, the only file systems mounted are / (root), /var, and /stand. (Two file system types, /proc and /dev/fd), are also mounted.) File systems for users' files are not mounted. With the commands available on the mounted file systems, you can manipulate the file systems or transition to other system states. Only essential kernel processes are kept running.
When the system is brought down to single-user state with init, all mounted file systems remain mounted and all processes started by init that should be running only in multi-user state 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 will be killed. This last condition insures that all port monitors started by the Service Access Controller (SAC) will be killed and all services started by these port monitors, including ttymon login services, will be killed. (The SAC is a daemon that maintains the port monitors on a server machine in the state specified by the system administrator.) Other processes not started directly by init (such as cron) will remain running.
When you change to single-user state 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.
When a UnixWare 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 will use the system state specified in that entry as the initial system state for the system. If there is no initdefault entry in inittab, init requests that the user enter a system state from the virtual system console (/dev/syscon).
If an S or s is entered, init takes the system to single-user state. When single-user state is entered, the user's current terminal becomes the virtual system console and is used from then on for interactions with init. Even after a reboot, init will try to continue to use the same virtual system console. If this device can no longer be accessed, the virtual system console will revert to the default console device, /dev/systty. The command /sbin/su is invoked and a message is generated on the physical console saying where the virtual console has been relocated. Use either init or telinit, to signal init to change the system state of the system. Note that if the shell is terminated (via an end-of-file), init will only re-initialize to the single-user state if the inittab file does not exist.
If a 0 through 6 is entered, init enters the corresponding system state. System states 0, 5, and 6 are reserved states for shutting the system down. System states 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 state 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 system state entered matches that of the entry. 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. init then scans inittab and executes all other entries that are to be processed for that system state.
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 state. 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.
When init comes up at boot time, ioctl settings from /etc/ioctl.syscon are saved internally. Whenever the system changes to the single-user state, and after the virtual console device has been established (that is, after the device from which you issued the init s command has been linked to /dev/syscon), the ioctl settings are retrieved from /dev/syscon and restored to /etc/ioctl.syscon. The ioctl values from /etc/ioctl.syscon are set on the virtual console device prior to a message being displayed by init. The ioctl values on the virtual console device are restored to their original values after the message is displayed.
When a system state change request is made, init sends the warning signal (SIGTERM) to all processes that are undefined in the target system state. 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 system state permits) before any further processing takes place. In this way init can perform various cleanup and recording functions during the powerdown of the operating system.
When attempting to boot the system, failure of init to prompt for a new system state may be because the virtual system console is linked to a device other than the physical system console.
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 will loop, that is, it will go to firmware and reboot continuously.
Messages generated from the kernel (for example,
Press any key to reboot ...
which is displayed as a result of entering the
command init 5),
are displayed on the default system console device.
If the utmp file cannot be created when booting the system, the system will boot to single-user state regardless of the state specified in the initdefault entry in the inittab file. This can happen if the /var file system is not accessible.
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 state when it cannot obtain a file descriptor to open the inittab file.