irix - init (1)
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. Have the
machine remove power if it can.
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
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), who(1), kill(2), 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.