1inittab(4)                       File Formats                       inittab(4)
2
3
4

NAME

6       inittab - script for init
7

DESCRIPTION

9       The  /etc/inittab  file  controls process dispatching by init. The pro‐
10       cesses most typically dispatched by init are daemons.
11
12
13       It is no longer necessary  to  edit  the  /etc/inittab  file  directly.
14       Administrators should use the Solaris Service Management Facility (SMF)
15       to define services instead. Refer to smf(5) and the System  Administra‐
16       tion Guide: Basic Administration for more information on SMF.
17
18
19       To modify parameters passed to ttymon(1M), use svccfg(1M) to modify the
20       SMF repository. See ttymon(1M) for details on the available SMF proper‐
21       ties.
22
23
24       The inittab file is composed of entries that are position dependent and
25       have the following format:
26
27
28       id:rstate:action:process
29
30
31       Each entry is delimited by a newline; however, a backslash (\)  preced‐
32       ing  a newline indicates a continuation of the entry. Up to 512 charac‐
33       ters for each entry are permitted. Comments  may  be  inserted  in  the
34       process  field  using  the  convention for comments described in sh(1).
35       There are no limits (other than maximum entry size) imposed on the num‐
36       ber of entries in the inittab file. The entry fields are:
37
38       id         One  to  four characters used to uniquely identify an entry.
39                  Do not use the characters "r" or "t" as the  first  or  only
40                  character  in  this field. These characters are reserved for
41                  the use of rlogin(1) and telnet(1).
42
43
44       rstate     Define the run level in which this entry is to be processed.
45                  Run-levels effectively correspond to a configuration of pro‐
46                  cesses in the system. That is, each process spawned by  init
47                  is  assigned a run level(s) in which it is allowed to exist.
48                  The run levels are represented by a number  ranging  from  0
49                  through  6.  For  example,  if the system is in run level 1,
50                  only those entries having a 1 in the rstate field  are  pro‐
51                  cessed.
52
53                  When  init  is requested to change run levels, all processes
54                  that do not have an entry in the rstate field for the target
55                  run  level are sent the warning signal SIGTERM and allowed a
56                  5-second grace period before being  forcibly  terminated  by
57                  the  kill signal SIGKILL. The rstate field can define multi‐
58                  ple run levels for a process by selecting more than one  run
59                  level  in  any combination from 0 through 6. If no run level
60                  is specified, then the process is assumed to be valid at all
61                  run levels 0 through 6.
62
63                  There  are  three other values, a, b and c, which can appear
64                  in the rstate field, even though they are not true run  lev‐
65                  els. Entries which have these characters in the rstate field
66                  are processed only when an init or telinit process  requests
67                  them  to  be run (regardless of the current run level of the
68                  system). See init(1M). These differ from run levels in  that
69                  init  can  never  enter run level a, b or c. Also, a request
70                  for the execution of any of these processes does not  change
71                  the  current run level. Furthermore, a process started by an
72                  a, b or c command is not killed when  init  changes  levels.
73                  They  are killed only if their line in inittab is marked off
74                  in the action field, their line  is  deleted  entirely  from
75                  inittab, or init goes into single-user state.
76
77
78       action     Key  words  in this field tell init how to treat the process
79                  specified in the process field. The  actions  recognized  by
80                  init are as follows:
81
82                  respawn      If  the  process does not exist, then start the
83                               process; do not wait for its termination  (con‐
84                               tinue  scanning the inittab file), and when the
85                               process  dies,  restart  the  process.  If  the
86                               process  currently  exists, do nothing and con‐
87                               tinue scanning the inittab file.
88
89
90                  wait         When init enters the run level that matches the
91                               entry's  rstate, start the process and wait for
92                               its termination. All subsequent  reads  of  the
93                               inittab  file  while  init  is  in the same run
94                               level cause init to ignore this entry.
95
96
97                  once         When init enters a run level that  matches  the
98                               entry's  rstate, start the process, do not wait
99                               for its  termination.  When  it  dies,  do  not
100                               restart  the  process. If init enters a new run
101                               level and the process is still running  from  a
102                               previous  run  level change, the program is not
103                               restarted.
104
105
106                  boot         The entry is to be  processed  only  at  init's
107                               boot-time  read of the inittab file. init is to
108                               start the process and not wait for its termina‐
109                               tion;  when  it  dies,  it does not restart the
110                               process. In order for this  instruction  to  be
111                               meaningful, the rstate should be the default or
112                               it must match init's run level  at  boot  time.
113                               This  action  is  useful  for an initialization
114                               function following a  hardware  reboot  of  the
115                               system.
116
117
118                  bootwait     The  entry  is  to  be processed the first time
119                               init goes from single-user to multi-user  state
120                               after  the  system  is  booted. init starts the
121                               process, waits for its termination and, when it
122                               dies, does not restart the process.
123
124
125                  powerfail    Execute  the process associated with this entry
126                               only when init receives a  power  fail  signal,
127                               SIGPWR (see signal(3C)).
128
129
130                  powerwait    Execute  the process associated with this entry
131                               only when init receives a  power  fail  signal,
132                               SIGPWR,  and  wait  until  it terminates before
133                               continuing any processing of inittab.
134
135
136                  off          If the process associated with  this  entry  is
137                               currently  running,  send  the  warning  signal
138                               SIGTERM and wait 5 seconds before forcibly ter‐
139                               minating  the  process  with  the  kill  signal
140                               SIGKILL. If the process is nonexistent,  ignore
141                               the entry.
142
143
144                  ondemand     This  instruction  is  really a synonym for the
145                               respawn action. It is functionally identical to
146                               respawn  but  is  given  a different keyword in
147                               order to divorce its association with run  lev‐
148                               els.  This instruction is used only with the a,
149                               b or c values described in the rstate field.
150
151
152                  sysinit      Entries of this type are executed  before  init
153                               tries  to  access  the console (that is, before
154                               the Console Login: prompt). It is expected that
155                               this  entry  will  be  used  only to initialize
156                               devices that init might  try  to  ask  the  run
157                               level  question. These entries are executed and
158                               init waits for their completion before continu‐
159                               ing.
160
161
162
163       process    Specify  a  command to be executed. The entire process field
164                  is prefixed with exec and passed to a forked  sh  as  sh  −c
165                  'exec  command'.  For  this  reason, any legal sh syntax can
166                  appear in the process field.
167
168

SEE ALSO

170       sh(1),  who(1),  init(1M),  svcadm(1M),   svc.startd(1M),   ttymon(1M),
171       exec(2), open(2), signal(3C), smf(5)
172
173
174       System Administration Guide: Basic Administration
175

NOTES

177       With  the  introduction of the service management facility, the system-
178       provided /etc/inittab file is greatly reduced from previous releases.
179
180
181       The initdefault entry is not recognized in Solaris 10. See  smf(5)  for
182       information  on  SMF  milestones,  and  svcadm(1M), which describes the
183       "svcadm milestone -d" command; this provides similar  functionality  to
184       modifying the initdefault entry in previous versions of the Solaris OS.
185
186
187
188SunOS 5.11                        9 Dec 2004                        inittab(4)
Impressum