1inittab(4) File Formats inittab(4)
2
6 inittab - script for init
7
9 The /etc/inittab file controls process dispatching by init. The pro‐
10 cesses most typically dispatched by init are daemons.
11 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 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 The inittab file is composed of entries that are position dependent and
25 have the following format:
26 id:rstate:action:process
29 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 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 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 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 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 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 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 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 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 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 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 powerfail Execute the process associated with this entry
126 only when init receives a power fail signal,
127 SIGPWR (see signal(3C)).
128 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 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 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 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 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
170 sh(1), who(1), init(1M), svcadm(1M), svc.startd(1M), ttymon(1M),
171 exec(2), open(2), signal(3C), smf(5)
172 System Administration Guide: Basic Administration
175
177 With the introduction of the service management facility, the system-
178 provided /etc/inittab file is greatly reduced from previous releases.
179 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.
185SunOS 5.11 9 Dec 2004 inittab(4)