init(1M) C2 Trusted DG/UX 5.4.2T init(1M)
NAME
init, telinit - process control initialization
SYNOPSIS
/sbin/init [0i123456KkSsTtQqabc]
/sbin/telinit [0i123456KkSsTtQqabc]
DESCRIPTION
init is a general process spawner. Its primary role is to create
processes from information stored in the file /etc/inittab [see
inittab(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 /etc/inittab. init
can be in one of eight run levels, 0-6 S (s) (run levels S and s are
identical). The run level changes when a privileged user runs
/sbin/init. This user-spawned init sends appropriate signals to the
original init spawned by the operating system when the system was
booted, telling it which run level to change to.
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.
i put the system in installation mode. All local file
systems are mounted and a small set of essential kernel
processes are running. The installman(1M) program is
invoked to perform initial installation steps.
1 put the system in system administrator mode. All file
systems are mounted. Only a small set of essential
kernel processes are left running. This mode is for
administrative tasks such as installing optional
utility packages. All files are accessible. If the
system was booted directly to run level 2, then no
users are logged in on the system. If /etc/inittab has
been configured to force login at single-user mode and
the system was first booted to single-user mode and
then to run level 1, then at most one user with
privilege appropriate to change run levels is logged
in.
2 put the system in multi-user mode. All multi-user
environment terminal processes and daemons are spawned.
This state is commonly referred to as the multi-user
state.
3 start the remote file sharing processes and daemons.
Licensed material--property of copyright holder(s) 1
init(1M) C2 Trusted DG/UX 5.4.2T init(1M)
Mount and advertise remote resources. Run level 3
extends multi-user mode and is known as the remote-
file-sharing state.
4 is available to be defined as an alternative multi-user
environment configuration. It is not necessary for
system operation and is usually not used.
5 Stop the system and go to the firmware monitor.
Bringing the system to this state is functionally
equivalent to bringing it to init state s then entering
the halt(1M) command.
6 Stop the system and reboot to the state defined by the
initdefault entry in /etc/inittab. Bringing the system
to this state is functionally equivalent to bringing it
to init state s then entering the reboot(1M) command.
a,b,c process only those /etc/inittab entries having the a,
b, or c run level set. These are pseudo-states, which
may be defined to run certain commands, but which do
not cause the current run level to change.
Q,q re-examine /etc/inittab.
S,s enter single-user mode. When this occurs, the terminal
which executed this command (init S) becomes the system
console. Single-user mode doesn't require the
existence of a properly formatted /etc/inittab file.
If /etc/inittab does not exist, then by default the
only legal run level that init can enter is the single-
user mode and init executes system console login
unconditionally. When the system comes up to S (s),
init tries to mount the root (/) and /usr filesystems
and only essential kernel processes are running.
When the system comes down to S or s, all mounted file
systems remain mounted, and all processes started by
init that should only be running in multi-user mode are
killed. In addition, any process that has a utmp entry
will be killed. This last condition insures that all
port monitors started by the SAC are killed and all
services started by these port monitors, including
ttymon login services, are killed. Other processes not
started directly by init will remain running. For
example, cron remains running.
T,t enter single-user mode from run level 1, 2, 3 or 4.
init T brings the system to the state it would be in if
it were booted up to single-user mode. To get to this
state, init first tries to execute rc.init S
>/dev/console 2>&1 to shutdown the system gracefully;
Licensed material--property of copyright holder(s) 2
init(1M) C2 Trusted DG/UX 5.4.2T init(1M)
the current login session will be terminated. If
rc.init S fails, init will shut down the system and
halt the processor(s). init T is similar to init S
except it kills all processes not required at single
user mode and attempts to unmount all unused
filesystems except / and /usr.
K,k enter single-user mode from run level 1, 2, 3 or 4 in
order to enforce system repair and reboot. init K
brings the system to the state it would be in if it
were booted up to single-user mode. To get to this
state, init first tries to execute rc.init S
>/dev/console 2>&1 to shutdown the system gracefully;
the current login session will be terminated. If
rc.init S fails, init will shut down the system and
halt the processor(s). init will not allow the
privileged user to move to run level 1, 2, 3 or 4.
init K is similar to init T except in order to bring
the system to run level 1, 2, 3 or 4, the privileged
user must first repair, then explicitly reboot the
system.
When a DG/UX system is booted, init is invoked and the following
occurs. First, init attempts to fsck and mount /usr using the /usr
entry in /etc/fstab. If there is no /etc/fstab but there is an
/etc/fstab.proto, init copies /etc/fstab.proto to /etc/fstab and then
attempts the mount operation. The sequence is equivalent to:
if [ ! -f /etc/fstab ] &&
[ -f /etc/fstab.proto ]
then
cp /etc/fstab.proto /etc/fstab
fi
mount -f /
fsck -xq /usr
mount /usr
Next, init looks in /etc/inittab for the initdefault entry [see
inittab(4)]. If there is one, init will usually use the run level
specified in that entry as the initial run level to enter. If there
is no initdefault entry in /etc/inittab, or the initdefault entry run
level is 0, 5 or 6 which would not allow the system to come up, init
requests that the user enter a run level from the virtual system
console. If an S (s) is entered, init goes to the single-user state.
If /usr was not mounted successfully, then single-user state is
entered regardless of the initdefault setting in inittab. In the
single-user state the virtual console terminal is assigned to the
user's terminal and is opened for reading and writing. If there is
no /etc/inittab entry having the action trusted_con, then init
invokes /sbin/su 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 run level of the system.
Licensed material--property of copyright holder(s) 3
init(1M) C2 Trusted DG/UX 5.4.2T init(1M)
Note that if the shell is terminated (via an end-of-file), init will
only re-initialize to the single-user state if the /etc/inittab file
does not exist.
If a 0 through 6 is entered, init enters the corresponding run level
if /usr is mounted. init will not permit a state change if /usr is
not mounted. 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 /etc/inittab for
boot and bootwait entries [see inittab(4)]. These entries are
performed before any other processing of /etc/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 file systems, can take place before users are allowed onto
the system. init then scans /etc/inittab and executes all other
entries that are to be processed for that run level.
To spawn each process in /etc/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 /etc/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 /etc/inittab. New entries can be added to /etc/inittab at
any time; however, init still waits for one of the above three
conditions to occur before re-examining /etc/inittab. To get around
this, init Q or init q command wakes init to re-examine /etc/inittab
immediately.
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).
The shell running on each terminal will terminate when the user types
an end-of-file or hangs up. When init receives a 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 init receives a powerfail signal (SIGPWR) it scans /etc/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.
Licensed material--property of copyright holder(s) 4
init(1M) C2 Trusted DG/UX 5.4.2T init(1M)
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
/etc/utmp
/etc/wtmp
/etc/ioctl.syscon
/dev/syscon
SEE ALSO
installman(1M), ttymon(1M), shutdown(1M), inittab(4), utmp(4),
termio(7).
login(1), sh(1), stty(1), who(1).
kill(2).
DIAGNOSTICS
If init finds that it is respawning an entry from /etc/inittab more
than ten times in two minutes, it will assume that there is an error
in the command string in the entry, and generate an error message on
the system console. It will then refuse 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 eating up system
resources when someone makes a typographical error in the inittab
file or a program is removed that is referenced in /etc/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
/etc/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
/etc/inittab, state s is entered.
If the utmp file cannot be created when booting the system, the
system will boot to state s regardless of the state specified in the
initdefault entry in /etc/inittab. This can happen if the root
filesystem is not accessible.
Users with appropriate privilege can cause init to shutdown the
system leaving it in single-user mode with a required login at the
physical system console by sending init (pid 1) a signal. SIGTERM is
the equivalent of init K and SIGUSR1 is the equivalent of init T.
Note that init S, init T, and init K all attempt to execute rc.init S
to bring the system down to single-user mode. The fact that rc.init
S successfully completes with exit status 0 does not necessarily mean
Licensed material--property of copyright holder(s) 5
init(1M) C2 Trusted DG/UX 5.4.2T init(1M)
that all filesystems have been successfully unmounted. It may still
be possible to perform destructive I/O on filesystems which are not
actually unmounted. The only way you can be absolutely certain all
filesystems were unmounted is by rebooting the system.
Licensed material--property of copyright holder(s) 6