System Administration Guide
Appendix A, Customizing UNIX system startup

Changing the /etc/inittab file

Changing the /etc/inittab file

The /etc/init program starts during the last phase of kernel initialization and has a ``process id'' (PID) of ``1''. The init process starts all other processes. The /etc/inittab file contains instructions for init. The init program reads the inittab file under three circumstances: at boot time, when an init-started process completes, and when the system administrator executes either the /etc/init or /bin/telinit command with a run-level argument. The arguments passed to init allow you to change the system run level or force init to examine the inittab file without changing the run level. When the system changes run levels, init scans inittab for instructions that apply to the new state.


NOTE: When you modify inittab, the change is only temporary because each time the kernel is relinked, a new inittab file is created. To change the initialization procedure permanently, you must also modify the source from which the inittab file is recreated. To add a new entry, append it to the /etc/conf/cf.d/init.base file. To modify an entry, locate and edit the existing entry in /etc/conf/cf.d/init.base or in one of the other component files in the /etc/conf/init.d directory.

The inittab file is made up of entries that contain four fields separated by colons:

label:run_level:action:process



Table A-1 inittab fields

 ----------------------------------------------------
 Field       Description
 ----------------------------------------------------
 label       a unique identification label of up to
             four characters
 run_level   the init level at which the entry is
             executed
 action      a keyword indicating the action that
             init is to take on the process
 process     the process init executes upon entering
             the specified run level
If there is more than one run level specified for an inittab entry, the levels appear in the second field without separators. If the run level field is empty, the entry is executed in all numeric run levels (0-6). When the run level changes, any process that does not have an entry for the new run level receives a warning signal (15). If the process does not terminate after 5 seconds, it receives a kill signal (9). The current state of the init process determines how it executes the inittab entry.

When the init program is initially invoked, it scans inittab for entries that contain the action keywords described in Table A-2. These entries are executed only during init's boot-time read of inittab. 

Table A-2 inittab single-user keywords

 ----------------------------------------------------
 Keyword       Description
 ----------------------------------------------------
 boot          starts the process and continues to
               the next entry without waiting for the
               process to complete.  When the process
               dies, init does not restart the
               process.
 bootwait      starts the process once and waits for
               it to terminate before going on to the
               next inittab entry.
 initdefault   determines which init level to enter
               initially, using the highest number in
               the ``run_level'' field.  If the
               ``run_level'' field is empty, init 
               interprets the run level as 0123456 
               and enters run level 6. If there is no
               initdefault entry in inittab, then
               init requests an initial run level
               from the user at boot time.
 sysinit       starts the process the first time init 
               reads the table and waits for it to
               terminate before going on to the next
               inittab entry.  Entries with the
               sysinit keyword are executed before
               init tries to access the console.
When the run level changes from single-user to a numeric run level (0-6), init scans entries with the actions in Table A-3 and executes only those entries with the appropriate ``run_level'' field set. 

Table A-3 inittab run_level field keywords

 -------------------------------------------------
 Keyword    Description
 -------------------------------------------------
 off        sends a warning signal, waits 5
            seconds, then sends the kill signal to
            the process if it is currently
            running.  If the process is not
            running, it ignores the inittab entry.
 once       starts the process and continues to
            the next entry without waiting for the
            process to complete.  When the process
            dies, init does not restart the
            process.
 ondemand   is functionally identical to respawn;
            the ondemand keyword is used only with
            the a, b, or c run-level values.
 respawn    starts the process if it is not
            currently running and continues to the
            next entry without waiting for it to
            complete; restarts the process when it
            dies.  If the process is already
            running, init ignores the inittab 
            entry.
 wait       starts the process and waits for it to
            complete before going on to the next
            inittab entry.
If the system hardware is capable of detecting power failure and init receives a power failure signal, init executes entries containing the actions shown in Table A-4 if the run level is appropriate. 

Table A-4 inittab powerfail keywords

 --------------------------------------------------
 Keyword     Description
 --------------------------------------------------
 powerfail   starts the process once and continues
             to the next entry without waiting for
             the process to complete.
 powerwait   starts the process once and waits for
             the process to complete before going
             on to the next entry in the table.
In the following example, the inittab entry sets the default run level for the system to single-user mode when init is initially invoked: 
   is:S:initdefault:


NOTE: The initdefault action is not associated with any process. The third colon (:) in this entry is necessary; if it is missing, init ignores the entire entry.

You can configure your system to come up in multiuser mode by editing this inittab entry, changing the ``S'' in the run-level field to a ``2''.

The following inittab entry runs the /etc/bcheckrc script when the system is booted (or rebooted) and waits for the process to complete before processing the next entry. (The bcheckrc script checks the filesystems and sets the date.)

   bchk::sysinit:/etc/bcheckrc </dev/console >/dev/console 2>&1
The init process also starts the /etc/getty program according to instructions in inittab. The getty (``get a tty'') program sets up communication between the system and terminals. For more information, see the getty(M) manual page.

The following example inittab entry tells init to start a getty process (if one does not already exist) for tty01 (the console) at 9600 baud when the current run level is 2:

   co:2:respawn:/etc/getty tty01 sc_m
The respawn action instructs init to restart the getty process each time it dies and to continue processing the next inittab entry without waiting for the current process to complete. By changing the action from respawn to wait, you tell init to wait until the current process has finished before reading the next entry in inittab.

See the inittab(F) manual page for a detailed description of the format of the inittab file and an explanation of the action keywords.

To make your changes to inittab effective immediately, execute the telinit Q command. This command causes init to reexamine the modified inittab file without changing the run level.