inittab(F)

inittab -- script for the init process

Format

id:rstate:action:process

Description

The inittab file supplies the script to init's role as a general process dispatcher. The process that constitutes the majority of init's process dispatching activities is the line process /etc/getty that initiates individual terminal lines. Other processes typically dispatched by init are daemons and the shell.

The inittab file is recreated automatically by idmkinit at boot time anytime the kernel has been reconfigured. To construct a new inittab file, idmkinit concatenates the device driver init files in /etc/conf/init.d onto the end of /etc/conf/init.d/kernel (the default inittab).

If you add an entry directly to inittab, the change exists only until the kernel is relinked. To add an entry permanently, you must also edit /etc/conf/init.d/kernel. The kernel file has the same format as inittab.

The inittab file is composed of entries that are position-dependent. Each entry is delimited by a new-line; however, a backslash (\) preceding a new-line indicates a continuation of the entry. Up to 512 characters per entry are permitted. Comments may be inserted in the ``process'' field using the sh convention for comments. Comments for lines that spawn gettys are displayed by the who command. It is expected that they will contain some information about the line such as the location. There are no limits (other than maximum entry size) imposed on the number of entries within the inittab file.

The four fields per entry in inittab or /etc/conf/init.d/kernel are:

id

This is up to four characters used to uniquely identify an entry.

rstate

This defines the run-level in which this entry is to be processed. Each process spawned by init is assigned one or more run-levels in this field at which it is allowed to exist. The run-levels are represented by the numbers from 0 through 6, and the letters S or s (see init(M)).

For example, init processes the entries which have a 2 (or no specified run-level) in this field when the system goes to run-level 2,

If no run-level is specified, the process is assumed to be valid at all run-levels. When the system first goes to single-user mode after being rebooted init only invokes entries which specify sysinit in their action field. Entries which specify (or imply) that they should be run when the system goes to single-user mode are only invoked when the system subsequently enters this run-level from one of run-levels 1 through 6. When init changes run-levels, it sends SIGTERM to processes which do not have an entry in this field for the target run-level (but not those without any entry). init allows these processes 20 seconds to die before being forcibly terminating them using SIGKILL.

Entries with values a, b, and c in this field are not true run-levels but are processed only when init requests them to be run (regardless of the current run-level of the system). They differ from run-levels in that init can never enter run-level a, b, or c. Also, a request for the execution of any of these processes does not change the current run-level. In addition, a process started by an a, b, or c command is not killed when init changes levels. They are only killed if their line in /etc/inittab is marked off in the action field, their line is deleted entirely from /etc/inittab, or init goes into the single-user state.

action

Key words in this field tell init how to treat the process specified in the process field.

init recognizes the following actions:

boot: The entry is to be processed only at init's boot-time read of the inittab file. init is to start the process, not wait for its termination; and when it dies, not restart the process. In order for this instruction to be meaningful, the rstate should be the default or it must match init's run-level at boot time. This action is useful for an initialization function following a hardware reboot of the system.
bootwait: The entry is to be processed the first time init goes from single-user to multi-user state after the system is booted. (If initdefault is set to 2, the process will run right after the boot.) init starts the process, waits for its termination and, when it dies, does not restart the process.
initdefault: An entry with this action is only scanned when init is initially invoked. init uses this entry, if it exists, to determine which run-level to enter initially. It does this by taking the highest run-level specified in the rstate field and using that as its initial state. If the rstate field is empty, it is interpreted as 0123456 and so init will enter run-level 6. Additionally, if init does not find an initdefault entry in /etc/inittab, then it will request an initial run-level from the user at reboot time.
off: If the process associated with this entry is currently running, send the warning signal (SIGTERM) and wait 20 seconds before forcibly terminating the process via the kill signal (SIGKILL). If the process is nonexistent, ignore the entry.
once: Upon init's entering a run-level that matches the entry's rstate, start the process; do not wait for its termination. When it dies, do not restart the process. If upon entering a new run-level, where the process is still running from a previous run-level change, the program will not be restarted.
ondemand: This instruction is really a synonym for the respawn action. It is functionally identical to respawn but is given a different keyword in order to divorce its association with run-levels. This is used only with the a, b, or c values described in the rstate field.
powerfail: Execute the process associated with this entry only when init receives a power fail signal (SIGPWR; see signal(S)).
powerwait: Execute the process associated with this entry only when init receives a power fail signal (SIGPWR) and wait until it terminates before continuing any processing of inittab.
respawn: If the process does not exist, then start the process; do not wait for its termination (continue scanning the inittab file), and when it dies, restart the process. If the process currently exists, then do nothing and continue scanning the inittab file.
sysinit: init executes these entries when the system first goes to single-user mode after being rebooted. It does not execute these entries if the system is subsequently put in single-user mode from any of run-levels 1 through 6. Entries with sysinit in their action field do not specify a run-level in their rstate field.
wait: Upon init's entering the run-level that matches the entry's rstate, start the process and wait for its termination. All subsequent reads of the inittab file while init is in the same run-level will cause init to ignore this entry.

process

This is a command to be executed by sh. The entire process field is passed to a forked sh to be run by init. For this reason, any legal sh syntax can appear in the process field. Comments can be inserted with the ; #comment syntax.

Notes

The SCO OpenServer Release 6.0.0 /etc/inittab file is now sourced from /etc/conf/init.d/kernel instead of the /etc/conf/cf.d/init.base file that was used on SCO OpenServer Release 5 systems.

Warning

Do not add identical entries to the /etc/conf/init.d/ files and /etc/conf/init.d/kernel, or duplicate entries will result in /etc/inittab.

Files