NAME

inittab − script for the init 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 composed of entries that are position dependent and have the following format:

id:rstate:action:process

Each entry is delimited by a newline, however, a backslash (\) preceding a newline 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(1) convention for comments.  Comments for lines that spawn gettys are displayed by the who(1) 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 entry fields are:

id This is one or two characters used to uniquely identify an entry. 

rstate This defines the run-level in which this entry is to be processed.  Run-levels effectively correspond to a configuration of processes in the system.  That is, each process spawned by init is assigned a run-level or run-levels in which it is allowed to exist.  The run-levels are represented by a number ranging from 0 through 6 or the letter s.  As an example, if the system is in run-level 1, only those entries having a 1 in the rstate field will be processed.  When init is requested to change run-levels, all processes which do not have an entry in the rstate field for the target run-level will be sent the warning signal (SIGTERM) and allowed a 20-second grace period before being forcibly terminated by a kill signal (SIGKILL).  The rstate field can define multiple run-levels for a process by selecting more than one run-level in any combination from 0−6.  If no run-level is specified, then the process is assumed to be valid at all run-levels 0−6.  Run-level s is used to indicate  single user mode.  This run level is used by the /etc/rc file when changing to single user mode.  There are three other values, a, b and c, which can appear in the rstate field, even though they are not true run-levels. Entries which have these characters in the rstate field are processed only when the telinit (see init(1M)) process 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. Furthermore, 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.  The actions recognized by init are as follows:

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. 

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. 

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. 

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 only at init’s boot-time read of the inittab file.  Init is to start the process, wait for its termination and, when it dies, not restart the process. 

powerfail Execute the process associated with this entry only when init receives a power fail signal (SIGPWR see signal(2)). 

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. 

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. 

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. 

initdefault An entry with this action is only scanned when init 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, this is interpreted as 0123456 and so init will enter run-level 6.  Also, the initdefault entry cannot specify that init start in the SINGLE USER state.  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. 

scan This entry specifies the amount of time init waits between periodic scans of the inittab file.  Init scans inittab when one of its decendent processes dies, it recieves a powerfail signal, it is signaled by init or telinit, or through the periodic scan feature.  The process field contains the time, in seconds, of this interval.  A negative value in the process field disables periodic scans of inittab.  If init does not find a scan entry in the inittab file, it assumes a default value of 300 seconds. 

sync This entry specifies the amount of time init waits between calls to sync(2).  The process field contains the time, in seconds, of this interval.  A negative value in the process field disables calls to sync(2).  If init does not find a sync entry in the inittab file, it assumes a default value of 60 seconds. 

sysinit Entries of this type are executed before init tries to access the console.  It is expected that this entry will be only used to initialize devices on which init might try to ask the run-level question.  These entries are executed and waited for before continuing.  A %H argument to sysinit commands is expanded by init to represent the boot options specified by p23 to boot(8).  Specifically, bit 2 is expands to the word single, and bit 400 expands to the word writable.

pseudo This entry is to be processed only at init’s boot-time read of the inittab file.  This entry is used to create entries in the utmp file for the pseudo-terminals used by TCP/IP network utilities (namely rlogin(1C)).  Without this entry, you will notice that users logged in via rlogin(1C) would not appear in the output generated by who(1).  The process field of the inittab entry should contain just the device name of the pseudo-terminal (i.e. ttyp0). 

process This is a sh command to be executed.  The entire process field is prefixed with exec and passed to a forked sh as sh −c ′exec command′. For this reason, any legal sh syntax can appear in the process field.  Comments can be inserted with the ; #comment syntax. 

FILES

/etc/inittab

SEE ALSO

exec(2), open(2), signal(2), flat(1M). 
getty(1M), init(1M) in the CX/UX Administrator’s Reference Manual.
sh(1), who(1) in the CX/UX User’s Reference Manual. 

BUGS

A getty should not run at the port which the flat panel is connected to. 

CX/UX Programmer’s Reference Manual