Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
inittab(4)			 File Formats			    inittab(4)

NAME
       inittab - script	for init

DESCRIPTION
       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.  Ad-
       ministrators  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-
       ties.

       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 (\)  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:

       id

	   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).

       rstate

	   Define 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(s) in which it	is allowed to exist. The run levels are	repre-
	   sented 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 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 5-second grace	period
	   before  being  forcibly terminated by the kill signal SIGKILL.  The
	   rstate field	can define multiple run	levels for a  process  by  se-
	   lecting  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  levels.  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  ac-
	   tion	 field,	 their	line is	deleted	entirely from inittab, or init
	   goes	into single-user state.

       action

	   Key words in	this field tell	init how to treat the  process	speci-
	   fied	 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	the process dies, restart the process. If the  process
	       currently  exists, do nothing and continue scanning the inittab
	       file.

	   wait

	       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.

	   once

	       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	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, 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 fol-
	       lowing a	hardware reboot	of the system.

	   bootwait

	       The entry is to be processed the	first time init	goes from sin-
	       gle-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.

	   powerfail

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

	   powerwait

	       Execute	the  process associated	with this entry	only when init
	       receives	a power	fail signal, SIGPWR, and wait until it	termi-
	       nates before continuing any processing of inittab.

	   off

	       If the process associated with this entry is currently running,
	       send the	warning	signal	SIGTERM	 and  wait  5  seconds	before
	       forcibly	 terminating the process with 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 differ-
	       ent 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.

	   sysinit

	       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  de-
	       vices  that init	might try to ask the run level question. These
	       entries are executed and	init waits for their completion	before
	       continuing.

       process

	   Specify  a command to be executed. The entire process field is pre-
	   fixed 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.

SEE ALSO
       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

NOTES
       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 "sv-
       cadm milestone -d" command; this	provides similar functionality to mod-
       ifying the initdefault entry in previous	versions of the	Solaris	OS.

SunOS 5.10			  9 Dec	2004			    inittab(4)

NAME | DESCRIPTION | SEE ALSO | NOTES

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=inittab&sektion=4&manpath=SunOS+5.10>

home | help