inittab man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



inittab(4)							    inittab(4)

NAME
     inittab - script for the init process

DESCRIPTION
     The /etc/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 started with a character other than # and ended by a
     newline.  Lines starting with # are ignored.  A backslash (\) preceding a
     newline indicates a continuation of the entry.  Up to 512 characters per
     entry are permitted.  Comments can be inserted in the process field using
     the sh(1) convention for comments.	 Comments in the process field of
     lines that spawn gettys are displayed by the who(1) command.  Such
     process field comments can contain information about the line such as its
     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 field, of up to four characters, is 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 the letter s (or S), or a
	       number ranging from 0 through 6.	 As an example, if the system
	       is in run-level 1, only those entries having a 1 in the rstate
	       field are processed.

	       When init is requested to change run-levels, all processes that
	       do not have an entry in the rstate field for the target run-
	       level are sent the warning signal (SIGTERM) and allowed a grace
	       period (see init(1M) for the length of this 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, s, and S.  If no run-level is specified, the process is
	       assumed to be valid at all run-levels.

									Page 1

inittab(4)							    inittab(4)

	       There are three other values, a, b, and c, that can appear in
	       the rstate field, even though they are not true run-levels.
	       Entries that 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
			    causes 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, the
			    process is still running from a previous run-level
			    change, the program is not 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 and not wait for its termination.
			    When it dies, init does 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 runs right after the boot.)	init

									Page 2

inittab(4)							    inittab(4)

			    starts the process, waits for its termination and,
			    when it dies, does 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
			    enters run-level 6.	 Additionally, if init does
			    not find an initdefault entry in /etc/inittab, it
			    requests an initial run-level from the user at
			    reboot time.

	       sysinit	    Entries of this type are executed before init
			    tries to access the console (before the Console
			    Login: prompt).  It is expected that this entry
			    will be used only to initialize devices on which
			    init might try to ask the run-level question.
			    These entries are executed and waited for before
			    continuing.

     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.

									Page 3

inittab(4)							    inittab(4)

FILES
     /etc/inittab

SEE ALSO
     getty(1M), init(1M), sh(1), who(1), exec(2), open(2), signal(2).

									Page 4

[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
...................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net