1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
|
use strict;
use warnings;
return [
{
'accept' => [
'.*',
{
'type' => 'leaf',
'value_type' => 'uniline',
'warn' => '$unknown_param_msg'
}
],
'element' => [
'FailureAction',
{
'choice' => [
'exit',
'exit-force',
'halt',
'halt-force',
'halt-immediate',
'kexec',
'kexec-force',
'none',
'poweroff',
'poweroff-force',
'poweroff-immediate',
'reboot',
'reboot-force',
'reboot-immediate',
'soft-reboot',
'soft-reboot-force'
],
'description' => 'Configure the action to take when the unit stops and enters a failed state or
inactive state. Takes one of C<none>, C<reboot>,
C<reboot-force>, C<reboot-immediate>, C<poweroff>,
C<poweroff-force>, C<poweroff-immediate>, C<exit>,
C<exit-force>, C<soft-reboot>, C<soft-reboot-force>,
C<kexec>, C<kexec-force>, C<halt>,
C<halt-force> and C<halt-immediate>. In system mode, all options are
allowed. In user mode, only C<none>, C<exit>, and
C<exit-force> are allowed. Both options default to C<none>.
If C<none> is set, no action will be triggered. C<reboot> causes a
reboot following the normal shutdown procedure (i.e. equivalent to systemctl
reboot). C<reboot-force> causes a forced reboot which will terminate all
processes forcibly but should cause no dirty file systems on reboot (i.e. equivalent to
systemctl reboot -f) and C<reboot-immediate> causes immediate
execution of the
L<reboot(2)> system
call, which might result in data loss (i.e. equivalent to systemctl reboot -ff).
Similarly, C<poweroff>, C<poweroff-force>,
C<poweroff-immediate>, C<kexec>, C<kexec-force>,
C<halt>, C<halt-force> and C<halt-immediate> have the
effect of powering down the system, executing kexec, and halting the system respectively with similar
semantics. C<exit> causes the manager to exit following the normal shutdown procedure,
and C<exit-force> causes it terminate without shutting down services. When
C<exit> or C<exit-force> is used by default the exit status of the main
process of the unit (if this applies) is returned from the service manager. However, this may be
overridden with
C<FailureActionExitStatus>/C<SuccessActionExitStatus>, see below.
C<soft-reboot> will trigger a userspace reboot operation.
C<soft-reboot-force> does that too, but does not go through the shutdown transaction
beforehand.',
'migrate_from' => {
'formula' => '$service',
'variables' => {
'service' => '- - Service FailureAction'
}
},
'type' => 'leaf',
'value_type' => 'enum'
},
'SuccessAction',
{
'choice' => [
'exit',
'exit-force',
'halt',
'halt-force',
'halt-immediate',
'kexec',
'kexec-force',
'none',
'poweroff',
'poweroff-force',
'poweroff-immediate',
'reboot',
'reboot-force',
'reboot-immediate',
'soft-reboot',
'soft-reboot-force'
],
'description' => 'Configure the action to take when the unit stops and enters a failed state or
inactive state. Takes one of C<none>, C<reboot>,
C<reboot-force>, C<reboot-immediate>, C<poweroff>,
C<poweroff-force>, C<poweroff-immediate>, C<exit>,
C<exit-force>, C<soft-reboot>, C<soft-reboot-force>,
C<kexec>, C<kexec-force>, C<halt>,
C<halt-force> and C<halt-immediate>. In system mode, all options are
allowed. In user mode, only C<none>, C<exit>, and
C<exit-force> are allowed. Both options default to C<none>.
If C<none> is set, no action will be triggered. C<reboot> causes a
reboot following the normal shutdown procedure (i.e. equivalent to systemctl
reboot). C<reboot-force> causes a forced reboot which will terminate all
processes forcibly but should cause no dirty file systems on reboot (i.e. equivalent to
systemctl reboot -f) and C<reboot-immediate> causes immediate
execution of the
L<reboot(2)> system
call, which might result in data loss (i.e. equivalent to systemctl reboot -ff).
Similarly, C<poweroff>, C<poweroff-force>,
C<poweroff-immediate>, C<kexec>, C<kexec-force>,
C<halt>, C<halt-force> and C<halt-immediate> have the
effect of powering down the system, executing kexec, and halting the system respectively with similar
semantics. C<exit> causes the manager to exit following the normal shutdown procedure,
and C<exit-force> causes it terminate without shutting down services. When
C<exit> or C<exit-force> is used by default the exit status of the main
process of the unit (if this applies) is returned from the service manager. However, this may be
overridden with
C<FailureActionExitStatus>/C<SuccessActionExitStatus>, see below.
C<soft-reboot> will trigger a userspace reboot operation.
C<soft-reboot-force> does that too, but does not go through the shutdown transaction
beforehand.',
'migrate_from' => {
'formula' => '$service',
'variables' => {
'service' => '- - Service SuccessAction'
}
},
'type' => 'leaf',
'value_type' => 'enum'
},
'StartLimitBurst',
{
'description' => 'Configure unit start rate limiting. Units which are started more than
burst times within an interval time span are
not permitted to start any more. Use C<StartLimitIntervalSec> to configure the
checking interval and C<StartLimitBurst> to configure how many starts per interval
are allowed.
interval is a time span with the default unit of seconds, but other
units may be specified, see
L<systemd.time(7)>.
The special value C<infinity> can be used to limit the total number of start
attempts, even if they happen at large time intervals.
Defaults to C<DefaultStartLimitIntervalSec> in manager configuration file, and may
be set to 0 to disable any kind of rate limiting. burst is a number and
defaults to C<DefaultStartLimitBurst> in manager configuration file.
These configuration options are particularly useful in conjunction with the service setting
C<Restart> (see
L<systemd.service(5)>);
however, they apply to all kinds of starts (including manual), not just those triggered by the
C<Restart> logic.
Note that units which are configured for C<Restart>, and which reach the start
limit are not attempted to be restarted anymore; however, they may still be restarted manually or
from a timer or socket at a later point, after the interval has passed.
From that point on, the restart logic is activated again. systemctl reset-failed
will cause the restart rate counter for a service to be flushed, which is useful if the administrator
wants to manually start a unit and the start limit interferes with that. Rate-limiting is enforced
after any unit condition checks are executed, and hence unit activations with failing conditions do
not count towards the rate limit.
When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters
are flushed out too. This means that configuring start rate limiting for a unit that is not
referenced continuously has no effect.
This setting does not apply to slice, target, device, and scope units, since they are unit
types whose activation may either never fail, or may succeed only a single time.',
'migrate_from' => {
'formula' => '$service',
'variables' => {
'service' => '- - Service StartLimitBurst'
}
},
'type' => 'leaf',
'value_type' => 'uniline'
},
'StartLimitIntervalSec',
{
'description' => 'Configure unit start rate limiting. Units which are started more than
burst times within an interval time span are
not permitted to start any more. Use C<StartLimitIntervalSec> to configure the
checking interval and C<StartLimitBurst> to configure how many starts per interval
are allowed.
interval is a time span with the default unit of seconds, but other
units may be specified, see
L<systemd.time(7)>.
The special value C<infinity> can be used to limit the total number of start
attempts, even if they happen at large time intervals.
Defaults to C<DefaultStartLimitIntervalSec> in manager configuration file, and may
be set to 0 to disable any kind of rate limiting. burst is a number and
defaults to C<DefaultStartLimitBurst> in manager configuration file.
These configuration options are particularly useful in conjunction with the service setting
C<Restart> (see
L<systemd.service(5)>);
however, they apply to all kinds of starts (including manual), not just those triggered by the
C<Restart> logic.
Note that units which are configured for C<Restart>, and which reach the start
limit are not attempted to be restarted anymore; however, they may still be restarted manually or
from a timer or socket at a later point, after the interval has passed.
From that point on, the restart logic is activated again. systemctl reset-failed
will cause the restart rate counter for a service to be flushed, which is useful if the administrator
wants to manually start a unit and the start limit interferes with that. Rate-limiting is enforced
after any unit condition checks are executed, and hence unit activations with failing conditions do
not count towards the rate limit.
When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters
are flushed out too. This means that configuring start rate limiting for a unit that is not
referenced continuously has no effect.
This setting does not apply to slice, target, device, and scope units, since they are unit
types whose activation may either never fail, or may succeed only a single time.',
'migrate_from' => {
'formula' => '$unit || $service',
'use_eval' => '1',
'variables' => {
'service' => '- - Service StartLimitInterval',
'unit' => '- StartLimitInterval'
}
},
'type' => 'leaf',
'value_type' => 'uniline'
},
'RebootArgument',
{
'description' => 'Configure the optional argument for the
L<reboot(2)> system call if
C<StartLimitAction> or C<FailureAction> is a reboot action. This
works just like the optional argument to systemctl reboot command.',
'migrate_from' => {
'formula' => '$service',
'variables' => {
'service' => '- - Service RebootArgument'
}
},
'type' => 'leaf',
'value_type' => 'uniline'
}
],
'include' => [
'Systemd::Section::Unit'
],
'name' => 'Systemd::Section::ServiceUnit'
}
]
;
|
