inittab man page on SmartOS

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

INITTAB(4)							    INITTAB(4)

       inittab - script for init

       The  /etc/inittab  file	controls process dispatching by init. The pro‐
       cesses most typically dispatched by init are daemons.

       It is no longer necessary  to  edit  the	 /etc/inittab  file  directly.
       Administrators should use the Solaris Service Management Facility (SMF)
       to define services instead. Refer to smf(5) and the System  Administra‐
       tion Guide: Basic Administration for more information on SMF.

       To modify parameters passed to ttymon(1M), use svccfg(1M) to modify the
       SMF repository. See ttymon(1M) for details on the available SMF proper‐

       The inittab file is composed of entries that are position dependent and
       have the following format:


       Each entry is delimited by a newline; however, a backslash (\)  preced‐
       ing  a newline indicates a continuation of the entry. Up to 512 charac‐
       ters for each entry are permitted. Comments  may	 be  inserted  in  the
       process	field  using  the  convention for comments described in sh(1).
       There are no limits (other than maximum entry size) imposed on the num‐
       ber of entries in the inittab file. The entry fields are:

		  One  to  four characters used to uniquely identify an entry.
		  Do not use the characters "r" or "t" as the  first  or  only
		  character  in	 this field. These characters are reserved for
		  the use of rlogin(1) and telnet(1).

		  Define the run level in which this entry is to be processed.
		  Run-levels effectively correspond to a configuration of pro‐
		  cesses in the system. That is, each process spawned by  init
		  is  assigned a run level(s) in which it is allowed to exist.
		  The run levels are represented by a number  ranging  from  0
		  through  6.  For  example,  if the system is in run level 1,
		  only those entries having a 1 in the rstate field  are  pro‐

		  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
		  5-second grace period before being  forcibly	terminated  by
		  the  kill signal SIGKILL. The rstate field can define multi‐
		  ple run levels for a process by selecting more than one  run
		  level	 in  any combination from 0 through 6. If no run level
		  is specified, then the process is assumed to be valid at all
		  run levels 0 through 6.

		  There	 are  three other values, a, b and c, which can appear
		  in the rstate field, even though they are not true run  lev‐
		  els. Entries which have these characters in the rstate field
		  are processed only when an init or telinit process  requests
		  them	to  be run (regardless of the current run level of the
		  system). See init(1M). These 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 killed only if their line in inittab is marked off
		  in the action field, their line  is  deleted	entirely  from
		  inittab, or init goes into single-user state.

		  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:

			       If  the	process does not exist, then start the
			       process; do not wait for its termination	 (con‐
			       tinue  scanning the inittab file), and when the
			       process	dies,  restart	the  process.  If  the
			       process	currently  exists, do nothing and con‐
			       tinue scanning the inittab file.

			       When init enters 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 cause init to ignore this entry.

			       When init enters 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 init enters a new run
			       level and the process is still running  from  a
			       previous	 run  level change, the program is not

			       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 termina‐
			       tion;  when  it	dies,  it 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

			       The  entry  is  to  be processed the first time
			       init goes from single-user to multi-user	 state
			       after  the  system  is  booted. init starts the
			       process, waits for its termination and, when it
			       dies, does not restart the process.

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

			       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.

			       If the process associated with  this  entry  is
			       currently  running,  send  the  warning	signal
			       SIGTERM and wait 5 seconds before forcibly ter‐
			       minating	 the  process  with  the  kill	signal
			       SIGKILL. If the process is nonexistent,	ignore
			       the entry.

			       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  lev‐
			       els.  This instruction is used only with the a,
			       b or c values described in the rstate field.

			       Entries of this type are executed  before  init
			       tries  to  access  the console (that is, before
			       the Console Login: prompt). It is expected that
			       this  entry  will  be  used  only to initialize
			       devices that init might	try  to	 ask  the  run
			       level  question. These entries are executed and
			       init waits for their completion before continu‐

		  Specify  a  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.

       sh(1),  who(1),	init(1M),  svcadm(1M),	 svc.startd(1M),   ttymon(1M),
       exec(2), open(2), signal(3C), smf(5)

       System Administration Guide: Basic Administration

       With  the  introduction of the service management facility, the system-
       provided /etc/inittab file is greatly reduced from previous releases.

       The initdefault entry is not recognized in Solaris 10. See  smf(5)  for
       information  on	SMF  milestones,  and  svcadm(1M), which describes the
       "svcadm milestone -d" command; this provides similar  functionality  to
       modifying the initdefault entry in previous versions of the Solaris OS.

				  Dec 9, 2004			    INITTAB(4)

List of man pages available for SmartOS

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]
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