File Coverage

blib/lib/Config/Model/models/Systemd/Section/Unit.pl
Criterion Covered Total %
statement 24 24 100.0
branch n/a
condition n/a
subroutine 8 8 100.0
pod n/a
total 32 32 100.0


line stmt bran cond sub pod time code
1             #
2             # This file is part of Config-Model-Systemd
3             #
4             # This software is Copyright (c) 2008-2022 by Dominique Dumont.
5             #
6             # This is free software, licensed under:
7             #
8             # The GNU Lesser General Public License, Version 2.1, February 1999
9             #
10 4     4   12437 use strict;
  4     1   9  
  4     1   91  
  1     1   2195  
  1         2  
  1         16  
  1         2237  
  1         2  
  1         16  
  1         2868  
  1         2  
  1         19  
11 4     4   17 use warnings;
  4     1   7  
  4     1   6303  
  1     1   6  
  1         2  
  1         1622  
  1         4  
  1         2  
  1         1571  
  1         5  
  1         3  
  1         1766  
12              
13             return [
14             {
15             'accept' => [
16             '.*',
17             {
18             'type' => 'leaf',
19             'value_type' => 'uniline',
20             'warn' => 'Unexpected systemd parameter. Please contact cme author to update systemd model.'
21             }
22             ],
23             'class_description' => "A unit file is a plain text ini-style file that encodes information about a service, a
24             socket, a device, a mount point, an automount point, a swap file or partition, a start-up
25             target, a watched file system path, a timer controlled and supervised by
26             L<systemd(1)>, a
27             resource management slice or a group of externally created processes. See
28             L<systemd.syntax(7)>
29             for a general description of the syntax.
30              
31             This man page lists the common configuration options of all
32             the unit types. These options need to be configured in the [Unit]
33             or [Install] sections of the unit files.
34              
35             In addition to the generic [Unit] and [Install] sections
36             described here, each unit may have a type-specific section, e.g.
37             [Service] for a service unit. See the respective man pages for
38             more information:
39             L<systemd.service(5)>,
40             L<systemd.socket(5)>,
41             L<systemd.device(5)>,
42             L<systemd.mount(5)>,
43             L<systemd.automount(5)>,
44             L<systemd.swap(5)>,
45             L<systemd.target(5)>,
46             L<systemd.path(5)>,
47             L<systemd.timer(5)>,
48             L<systemd.slice(5)>,
49             L<systemd.scope(5)>.
50              
51              
52             Unit files are loaded from a set of paths determined during compilation, described in the next
53             section.
54              
55             Valid unit names consist of a \"name prefix\" and a dot and a suffix specifying the unit type. The
56             \"unit prefix\" must consist of one or more valid characters (ASCII letters, digits, C<:>,
57             C<->, C<_>, C<.>, and C<\\>). The total
58             length of the unit name including the suffix must not exceed 256 characters. The type suffix must be one
59             of C<.service>, C<.socket>, C<.device>,
60             C<.mount>, C<.automount>, C<.swap>,
61             C<.target>, C<.path>, C<.timer>,
62             C<.slice>, or C<.scope>.
63              
64             Units names can be parameterized by a single argument called the \"instance name\". The unit is then
65             constructed based on a \"template file\" which serves as the definition of multiple services or other
66             units. A template unit must have a single C<\@> at the end of the name (right before the
67             type suffix). The name of the full unit is formed by inserting the instance name between
68             C<\@> and the unit type suffix. In the unit file itself, the instance parameter may be
69             referred to using C<%i> and other specifiers, see below.
70              
71             Unit files may contain additional options on top of those listed here. If systemd encounters an
72             unknown option, it will write a warning log message but continue loading the unit. If an option or
73             section name is prefixed with C<X->, it is ignored completely by systemd. Options within an
74             ignored section do not need the prefix. Applications may use this to include additional information in
75             the unit files. To access those options, applications need to parse the unit files on their own.
76              
77             Units can be aliased (have an alternative name), by creating a symlink from the new name to the
78             existing name in one of the unit search paths. For example, C<systemd-networkd.service>
79             has the alias C<dbus-org.freedesktop.network1.service>, created during installation as
80             a symlink, so when systemd is asked through D-Bus to load
81             C<dbus-org.freedesktop.network1.service>, it'll load
82             C<systemd-networkd.service>. As another example, C<default.target> \x{2014}
83             the default system target started at boot \x{2014} is commonly aliased to either
84             C<multi-user.target> or C<graphical.target> to select what is started
85             by default. Alias names may be used in commands like disable,
86             start, stop, status, and similar, and in all
87             unit dependency directives, including C<Wants>, C<Requires>,
88             C<Before>, C<After>. Aliases cannot be used with the
89             preset command.
90              
91             Aliases obey the following restrictions: a unit of a certain type (C<.service>,
92             C<.socket>, \x{2026}) can only be aliased by a name with the same type suffix. A plain unit (not
93             a template or an instance), may only be aliased by a plain name. A template instance may only be aliased
94             by another template instance, and the instance part must be identical. A template may be aliased by
95             another template (in which case the alias applies to all instances of the template). As a special case, a
96             template instance (e.g. C<alias\@inst.service>) may be a symlink to different template
97             (e.g. C<template\@inst.service>). In that case, just this specific instance is aliased,
98             while other instances of the template (e.g. C<alias\@foo.service>,
99             C<alias\@bar.service>) are not aliased. Those rules preserve the requirement that the
100             instance (if any) is always uniquely defined for a given unit and all its aliases. The target of alias
101             symlink must point to a valid unit file location, i.e. the symlink target name must match the symlink
102             source name as described, and the destination path must be in one of the unit search paths, see UNIT FILE
103             LOAD PATH section below for more details. Note that the target file may not exist, i.e. the symlink may
104             be dangling.
105              
106             Unit files may specify aliases through the C<Alias> directive in the [Install]
107             section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is
108             disabled. For example, C<reboot.target> specifies
109             C<Alias=ctrl-alt-del.target>, so when enabled, the symlink
110             C</etc/systemd/system/ctrl-alt-del.service> pointing to the
111             C<reboot.target> file will be created, and when
112             CtrlAltDel is invoked,
113             systemd will look for the C<ctrl-alt-del.service> and execute
114             C<reboot.service>. systemd does not look at the [Install] section at
115             all during normal operation, so any directives in that section only have an effect through the symlinks
116             created during enablement.
117              
118             Along with a unit file C<foo.service>, the directory
119             C<foo.service.wants/> may exist. All unit files symlinked from such a directory are
120             implicitly added as dependencies of type C<Wants> to the unit. Similar functionality
121             exists for C<Requires> type dependencies as well, the directory suffix is
122             C<.requires/> in this case. This functionality is useful to hook units into the
123             start-up of other units, without having to modify their unit files. For details about the semantics of
124             C<Wants> and C<Requires>, see below. The preferred way to create
125             symlinks in the C<.wants/> or C<.requires/> directories is by
126             specifying the dependency in [Install] section of the target unit, and creating the symlink in the file
127             system with the enable or preset commands of
128             L<systemctl(1)>. The
129             target can be a normal unit (either plain or a specific instance of a template unit). In case when the
130             source unit is a template, the target can also be a template, in which case the instance will be
131             \"propagated\" to the target unit to form a valid unit instance. The target of symlinks in
132             C<.wants/> or C<.requires/> must thus point to a valid unit file
133             location, i.e. the symlink target name must satisfy the described requirements, and the destination path
134             must be in one of the unit search paths, see UNIT FILE LOAD PATH section below for more details. Note
135             that the target file may not exist, i.e. the symlink may be dangling.
136              
137             Along with a unit file C<foo.service>, a \"drop-in\" directory
138             C<foo.service.d/> may exist. All files with the suffix
139             C<.conf> from this directory will be merged in the alphanumeric order and parsed
140             after the main unit file itself has been parsed. This is useful to alter or add configuration
141             settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate
142             section headers. For instantiated units, this logic will first look for the instance
143             C<.d/> subdirectory (e.g. C<foo\@bar.service.d/>) and read its
144             C<.conf> files, followed by the template C<.d/> subdirectory (e.g.
145             C<foo\@.service.d/>) and the C<.conf> files there. Moreover for unit
146             names containing dashes (C<->), the set of directories generated by repeatedly
147             truncating the unit name after all dashes is searched too. Specifically, for a unit name
148             C<foo-bar-baz.service> not only the regular drop-in directory
149             C<foo-bar-baz.service.d/> is searched but also both C<foo-bar-.service.d/> and
150             C<foo-.service.d/>. This is useful for defining common drop-ins for a set of related units, whose
151             names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose
152             systematic naming structure is built around dashes as component separators. Note that equally named drop-in files
153             further down the prefix hierarchy override those further up,
154             i.e. C<foo-bar-.service.d/10-override.conf> overrides
155             C<foo-.service.d/10-override.conf>.
156              
157             In cases of unit aliases (described above), dropins for the aliased name and all aliases are
158             loaded. In the example of C<default.target> aliasing
159             C<graphical.target>, C<default.target.d/>,
160             C<default.target.wants/>, C<default.target.requires/>,
161             C<graphical.target.d/>, C<graphical.target.wants/>,
162             C<graphical.target.requires/> would all be read. For templates, dropins for the
163             template, any template aliases, the template instance, and all alias instances are read. When just a
164             specific template instance is aliased, then the dropins for the target template, the target template
165             instance, and the alias template instance are read.
166              
167             In addition to C</etc/systemd/system>, the drop-in C<.d/>
168             directories for system services can be placed in C</usr/lib/systemd/system> or
169             C</run/systemd/system> directories. Drop-in files in C</etc/>
170             take precedence over those in C</run/> which in turn take precedence over those
171             in C</usr/lib/>. Drop-in files under any of these directories take precedence
172             over unit files wherever located. Multiple drop-in files with different names are applied in
173             lexicographic order, regardless of which of the directories they reside in.
174              
175             Units also support a top-level drop-in with C<type.d/>,
176             where type may be e.g. C<service> or C<socket>,
177             that allows altering or adding to the settings of all corresponding unit files on the system.
178             The formatting and precedence of applying drop-in configurations follow what is defined above.
179             Files in C<type.d/> have lower precedence compared
180             to files in name-specific override directories. The usual rules apply: multiple drop-in files
181             with different names are applied in lexicographic order, regardless of which of the directories
182             they reside in, so a file in C<type.d/> applies
183             to a unit only if there are no drop-ins or masks with that name in directories with higher
184             precedence. See Examples.
185              
186             Note that while systemd offers a flexible dependency system
187             between units it is recommended to use this functionality only
188             sparingly and instead rely on techniques such as bus-based or
189             socket-based activation which make dependencies implicit,
190             resulting in a both simpler and more flexible system.
191              
192             As mentioned above, a unit may be instantiated from a template file. This allows creation
193             of multiple units from a single configuration file. If systemd looks for a unit configuration
194             file, it will first search for the literal unit name in the file system. If that yields no
195             success and the unit name contains an C<\@> character, systemd will look for a
196             unit template that shares the same name but with the instance string (i.e. the part between the
197             C<\@> character and the suffix) removed. Example: if a service
198             C<getty\@tty3.service> is requested and no file by that name is found, systemd
199             will look for C<getty\@.service> and instantiate a service from that
200             configuration file if it is found.
201              
202             To refer to the instance string from within the
203             configuration file you may use the special C<%i>
204             specifier in many of the configuration options. See below for
205             details.
206              
207             If a unit file is empty (i.e. has the file size 0) or is
208             symlinked to C</dev/null>, its configuration
209             will not be loaded and it appears with a load state of
210             C<masked>, and cannot be activated. Use this as an
211             effective way to fully disable a unit, making it impossible to
212             start it even manually.
213              
214             The unit file format is covered by the
215             L<Interface
216             Portability and Stability Promise|https://systemd.io/PORTABILITY_AND_STABILITY/>.
217              
218             The set of load paths for the user manager instance may be augmented or
219             changed using various environment variables. And environment variables may in
220             turn be set using environment generators, see
221             L<systemd.environment-generator(7)>.
222             In particular, C<\$XDG_DATA_HOME> and
223             C<\$XDG_DATA_DIRS> may be easily set using
224             L<systemd-environment-d-generator(8)>.
225             Thus, directories listed here are just the defaults. To see the actual list that
226             would be used based on compilation options and current environment use
227              
228              
229             +-+systemd-analyze --user unit-paths
230              
231              
232              
233             Moreover, additional units might be loaded into systemd from directories not on the unit load path
234             by creating a symlink pointing to a unit file in the directories. You can use systemctl
235             link for this; see
236             L<systemctl(1)>. The file
237             system where the linked unit files are located must be accessible when systemd is started (e.g. anything
238             underneath C</home/> or C</var/> is not allowed, unless those
239             directories are located on the root file system).
240              
241             It is important to distinguish \"linked unit files\" from \"unit file aliases\": any symlink where the
242             symlink target is within the unit load path becomes an alias: the source name and
243             the target file name must satisfy specific constraints listed above in the discussion of aliases, but the
244             symlink target doesn't have to exist, and in fact the symlink target path is not used, except to check
245             whether the target is within the unit load path. In contrast, a symlink which goes outside of the unit
246             load path signifies a linked unit file. The symlink is followed when loading the file, but the
247             destination name is otherwise unused (and may even not be a valid unit file name). For example, symlinks
248             C</etc/systemd/system/alias1.service> \x{2192} C<service1.service>,
249             C</etc/systemd/system/alias2.service> \x{2192} C</usr/lib/systemd/service1.service>,
250             C</etc/systemd/system/alias3.service> \x{2192} C</etc/systemd/system/service1.service>
251             are all valid aliases and C<service1.service> will have
252             four names, even if the unit file is located at
253             C</run/systemd/system/service1.service>. In contrast,
254             a symlink C</etc/systemd/system/link1.service> \x{2192} C<../link1_service_file>
255             means that C<link1.service> is a \"linked unit\" and the contents of
256             C</etc/systemd/link1_service_file> provide its configuration.
257              
258             Unit files may also include a number of C<Condition\x{2026}=> and C<Assert\x{2026}=> settings. Before the unit is started, systemd will verify that the
259             specified conditions and asserts are true. If not, the starting of the unit will be (mostly silently)
260             skipped (in case of conditions), or aborted with an error message (in case of asserts). Failing
261             conditions or asserts will not result in the unit being moved into the C<failed>
262             state. The conditions and asserts are checked at the time the queued start job is to be executed. The
263             ordering dependencies are still respected, so other units are still pulled in and ordered as if this
264             unit was successfully activated, and the conditions and asserts are executed the precise moment the
265             unit would normally start and thus can validate system state after the units ordered before completed
266             initialization. Use condition expressions for skipping units that do not apply to the local system, for
267             example because the kernel or runtime environment doesn't require their functionality.
268              
269              
270             If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a
271             logical AND is applied). Condition checks can use a pipe symbol (C<|>) after the equals
272             sign (C<Condition\x{2026}=|\x{2026}>), which causes the condition to become a
273             triggering condition. If at least one triggering condition is defined for a unit,
274             then the unit will be started if at least one of the triggering conditions of the unit applies and all
275             of the regular (i.e. non-triggering) conditions apply. If you prefix an argument with the pipe symbol
276             and an exclamation mark, the pipe symbol must be passed first, the exclamation second. If any of these
277             options is assigned the empty string, the list of conditions is reset completely, all previous
278             condition settings (of any kind) will have no effect.
279              
280             The C<AssertArchitecture>, C<AssertVirtualization>, \x{2026} options
281             are similar to conditions but cause the start job to fail (instead of being skipped). The failed check
282             is logged. Units with failed conditions are considered to be in a clean state and will be garbage
283             collected if they are not referenced. This means that when queried, the condition failure may or may
284             not show up in the state of the unit.
285              
286             Note that neither assertion nor condition expressions result in unit state changes. Also note
287             that both are checked at the time the job is to be executed, i.e. long after depending jobs and it
288             itself were queued. Thus, neither condition nor assertion expressions are suitable for conditionalizing
289             unit dependencies.
290              
291             The condition verb of
292             L<systemd-analyze(1)> can
293             be used to test condition and assert expressions.
294              
295             Except for C<ConditionPathIsSymbolicLink>, all path checks follow symlinks.
296             This configuration class was generated from systemd documentation.
297             by L<parse-man.pl|https://github.com/dod38fr/config-model-systemd/contrib/parse-man.pl>
298             ",
299             'copyright' => [
300             '2010-2016 Lennart Poettering and others',
301             '2016 Dominique Dumont'
302             ],
303             'element' => [
304             'Description',
305             {
306             'description' => 'A short human readable title of the unit. This may be used by
307             systemd (and other UIs) as a user-visible label for the unit, so this string
308             should identify the unit rather than describe it, despite the name. This string also shouldn\'t just
309             repeat the unit name. C<Apache2 Web Server> is a good example. Bad examples are
310             C<high-performance light-weight HTTP server> (too generic) or
311             C<Apache2> (meaningless for people who do not know Apache, duplicates the unit
312             name). systemd may use this string as a noun in status messages (C<Starting
313             description...>, C<Started
314             description.>, C<Reached target
315             description.>, C<Failed to start
316             description.>), so it should be capitalized, and should not be a
317             full sentence, or a phrase with a continuous verb. Bad examples include C<exiting the
318             container> or C<updating the database once per day.>.',
319             'type' => 'leaf',
320             'value_type' => 'uniline'
321             },
322             'Documentation',
323             {
324             'cargo' => {
325             'type' => 'leaf',
326             'value_type' => 'uniline'
327             },
328             'description' => 'A space-separated list of URIs referencing
329             documentation for this unit or its configuration. Accepted are
330             only URIs of the types C<http://>,
331             C<https://>, C<file:>,
332             C<info:>, C<man:>. For more
333             information about the syntax of these URIs, see L<uri(7)>.
334             The URIs should be listed in order of relevance, starting with
335             the most relevant. It is a good idea to first reference
336             documentation that explains what the unit\'s purpose is,
337             followed by how it is configured, followed by any other
338             related documentation. This option may be specified more than
339             once, in which case the specified list of URIs is merged. If
340             the empty string is assigned to this option, the list is reset
341             and all prior assignments will have no
342             effect.',
343             'type' => 'list'
344             },
345             'Wants',
346             {
347             'cargo' => {
348             'type' => 'leaf',
349             'value_type' => 'uniline'
350             },
351             'description' => 'Configures (weak) requirement dependencies on other units. This option may be
352             specified more than once or multiple space-separated units may be specified in one option in which
353             case dependencies for all listed names will be created. Dependencies of this type may also be
354             configured outside of the unit configuration file by adding a symlink to a
355             C<.wants/> directory accompanying the unit file. For details, see above.
356              
357             Units listed in this option will be started if the configuring unit is. However, if the listed
358             units fail to start or cannot be added to the transaction, this has no impact on the validity of the
359             transaction as a whole, and this unit will still be started. This is the recommended way to hook
360             the start-up of one unit to the start-up of another unit.
361              
362             Note that requirement dependencies do not influence the order in which services are started or
363             stopped. This has to be configured independently with the C<After> or
364             C<Before> options. If unit C<foo.service> pulls in unit
365             C<bar.service> as configured with C<Wants> and no ordering is
366             configured with C<After> or C<Before>, then both units will be
367             started simultaneously and without any delay between them if C<foo.service> is
368             activated.',
369             'type' => 'list'
370             },
371             'Requires',
372             {
373             'cargo' => {
374             'type' => 'leaf',
375             'value_type' => 'uniline'
376             },
377             'description' => "Similar to C<Wants>, but declares a stronger requirement
378             dependency. Dependencies of this type may also be configured by adding a symlink to a
379             C<.requires/> directory accompanying the unit file.
380              
381             If this unit gets activated, the units listed will be activated as well. If one of
382             the other units fails to activate, and an ordering dependency C<After> on the
383             failing unit is set, this unit will not be started. Besides, with or without specifying
384             C<After>, this unit will be stopped (or restarted) if one of the other units is
385             explicitly stopped (or restarted).
386              
387             Often, it is a better choice to use C<Wants> instead of
388             C<Requires> in order to achieve a system that is more robust when dealing with
389             failing services.
390              
391             Note that this dependency type does not imply that the other unit always has to be in active state when
392             this unit is running. Specifically: failing condition checks (such as C<ConditionPathExists>,
393             C<ConditionPathIsSymbolicLink>, \x{2026} \x{2014} see below) do not cause the start job of a unit with a
394             C<Requires> dependency on it to fail. Also, some unit types may deactivate on their own (for
395             example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not
396             propagated to units having a C<Requires> dependency. Use the C<BindsTo>
397             dependency type together with C<After> to ensure that a unit may never be in active state
398             without a specific other unit also in active state (see below).",
399             'type' => 'list'
400             },
401             'Requisite',
402             {
403             'cargo' => {
404             'type' => 'leaf',
405             'value_type' => 'uniline'
406             },
407             'description' => 'Similar to C<Requires>. However, if the units listed here
408             are not started already, they will not be started and the starting of this unit will fail
409             immediately. C<Requisite> does not imply an ordering dependency, even if
410             both units are started in the same transaction. Hence this setting should usually be
411             combined with C<After>, to ensure this unit is not started before the other
412             unit.
413              
414             When C<Requisite=b.service> is used on
415             C<a.service>, this dependency will show as
416             C<RequisiteOf=a.service> in property listing of
417             C<b.service>. C<RequisiteOf>
418             dependency cannot be specified directly.',
419             'type' => 'list'
420             },
421             'BindsTo',
422             {
423             'cargo' => {
424             'type' => 'leaf',
425             'value_type' => 'uniline'
426             },
427             'description' => "Configures requirement dependencies, very similar in style to
428             C<Requires>. However, this dependency type is stronger: in addition to the effect of
429             C<Requires> it declares that if the unit bound to is stopped, this unit will be stopped
430             too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too.
431             Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit
432             might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of
433             a mount unit might be unmounted without involvement of the system and service manager.
434              
435             When used in conjunction with C<After> on the same unit the behaviour of
436             C<BindsTo> is even stronger. In this case, the unit bound to strictly has to be in active
437             state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly
438             enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition
439             check (such as C<ConditionPathExists>, C<ConditionPathIsSymbolicLink>, \x{2026} \x{2014}
440             see below) will be stopped, should it be running. Hence, in many cases it is best to combine
441             C<BindsTo> with C<After>.
442              
443             When C<BindsTo=b.service> is used on
444             C<a.service>, this dependency will show as
445             C<BoundBy=a.service> in property listing of
446             C<b.service>. C<BoundBy>
447             dependency cannot be specified directly.",
448             'type' => 'list'
449             },
450             'PartOf',
451             {
452             'cargo' => {
453             'type' => 'leaf',
454             'value_type' => 'uniline'
455             },
456             'description' => "Configures dependencies similar to
457             C<Requires>, but limited to stopping and
458             restarting of units. When systemd stops or restarts the units
459             listed here, the action is propagated to this unit. Note that
460             this is a one-way dependency\x{a0}\x{2014} changes to this unit do not
461             affect the listed units.
462              
463             When C<PartOf=b.service> is used on
464             C<a.service>, this dependency will show as
465             C<ConsistsOf=a.service> in property listing of
466             C<b.service>. C<ConsistsOf>
467             dependency cannot be specified directly.",
468             'type' => 'list'
469             },
470             'Upholds',
471             {
472             'description' => 'Configures dependencies similar to C<Wants>, but as long as this unit
473             is up, all units listed in C<Upholds> are started whenever found to be inactive or
474             failed, and no job is queued for them. While a C<Wants> dependency on another unit
475             has a one-time effect when this units started, a C<Upholds> dependency on it has a
476             continuous effect, constantly restarting the unit if necessary. This is an alternative to the
477             C<Restart> setting of service units, to ensure they are kept running whatever
478             happens.
479              
480             When C<Upholds=b.service> is used on C<a.service>, this
481             dependency will show as C<UpheldBy=a.service> in the property listing of
482             C<b.service>. The C<UpheldBy> dependency cannot be specified
483             directly.',
484             'type' => 'leaf',
485             'value_type' => 'uniline'
486             },
487             'Conflicts',
488             {
489             'cargo' => {
490             'type' => 'leaf',
491             'value_type' => 'uniline'
492             },
493             'description' => 'A space-separated list of unit names. Configures negative requirement
494             dependencies. If a unit has a C<Conflicts> setting on another unit, starting the
495             former will stop the latter and vice versa.
496              
497             Note that this setting does not imply an ordering dependency, similarly to the
498             C<Wants> and C<Requires> dependencies described above. This means
499             that to ensure that the conflicting unit is stopped before the other unit is started, an
500             C<After> or C<Before> dependency must be declared. It doesn\'t
501             matter which of the two ordering dependencies is used, because stop jobs are always ordered before
502             start jobs, see the discussion in C<Before>/C<After> below.
503              
504             If unit A that conflicts with unit B is scheduled to
505             be started at the same time as B, the transaction will either
506             fail (in case both are required parts of the transaction) or be
507             modified to be fixed (in case one or both jobs are not a
508             required part of the transaction). In the latter case, the job
509             that is not required will be removed, or in case both are
510             not required, the unit that conflicts will be started and the
511             unit that is conflicted is stopped.',
512             'type' => 'list'
513             },
514             'Before',
515             {
516             'cargo' => {
517             'type' => 'leaf',
518             'value_type' => 'uniline'
519             },
520             'description' => 'These two settings expect a space-separated list of unit names. They may be specified
521             more than once, in which case dependencies for all listed names are created.
522              
523             Those two settings configure ordering dependencies between units. If unit
524             C<foo.service> contains the setting C<Before=bar.service> and both
525             units are being started, C<bar.service>\'s start-up is delayed until
526             C<foo.service> has finished starting up. C<After> is the inverse
527             of C<Before>, i.e. while C<Before> ensures that the configured unit
528             is started before the listed unit begins starting up, C<After> ensures the opposite,
529             that the listed unit is fully started up before the configured unit is started.
530              
531             When two units with an ordering dependency between them are shut down, the inverse of the
532             start-up order is applied. I.e. if a unit is configured with C<After> on another
533             unit, the former is stopped before the latter if both are shut down. Given two units with any
534             ordering dependency between them, if one unit is shut down and the other is started up, the shutdown
535             is ordered before the start-up. It doesn\'t matter if the ordering dependency is
536             C<After> or C<Before>, in this case. It also doesn\'t matter which
537             of the two is shut down, as long as one is shut down and the other is started up; the shutdown is
538             ordered before the start-up in all cases. If two units have no ordering dependencies between them,
539             they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit
540             type when precisely a unit has finished starting up. Most importantly, for service units start-up is
541             considered completed for the purpose of C<Before>/C<After> when all
542             its configured start-up commands have been invoked and they either failed or reported start-up
543             success. Note that this does includes C<ExecStartPost> (or
544             C<ExecStopPost> for the shutdown case).
545              
546             Note that those settings are independent of and orthogonal to the requirement dependencies as
547             configured by C<Requires>, C<Wants>, C<Requisite>,
548             or C<BindsTo>. It is a common pattern to include a unit name in both the
549             C<After> and C<Wants> options, in which case the unit listed will
550             be started before the unit that is configured with these options.
551              
552             Note that C<Before> dependencies on device units have no effect and are not
553             supported. Devices generally become available as a result of an external hotplug event, and systemd
554             creates the corresponding device unit without delay.',
555             'type' => 'list'
556             },
557             'After',
558             {
559             'cargo' => {
560             'type' => 'leaf',
561             'value_type' => 'uniline'
562             },
563             'description' => 'These two settings expect a space-separated list of unit names. They may be specified
564             more than once, in which case dependencies for all listed names are created.
565              
566             Those two settings configure ordering dependencies between units. If unit
567             C<foo.service> contains the setting C<Before=bar.service> and both
568             units are being started, C<bar.service>\'s start-up is delayed until
569             C<foo.service> has finished starting up. C<After> is the inverse
570             of C<Before>, i.e. while C<Before> ensures that the configured unit
571             is started before the listed unit begins starting up, C<After> ensures the opposite,
572             that the listed unit is fully started up before the configured unit is started.
573              
574             When two units with an ordering dependency between them are shut down, the inverse of the
575             start-up order is applied. I.e. if a unit is configured with C<After> on another
576             unit, the former is stopped before the latter if both are shut down. Given two units with any
577             ordering dependency between them, if one unit is shut down and the other is started up, the shutdown
578             is ordered before the start-up. It doesn\'t matter if the ordering dependency is
579             C<After> or C<Before>, in this case. It also doesn\'t matter which
580             of the two is shut down, as long as one is shut down and the other is started up; the shutdown is
581             ordered before the start-up in all cases. If two units have no ordering dependencies between them,
582             they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit
583             type when precisely a unit has finished starting up. Most importantly, for service units start-up is
584             considered completed for the purpose of C<Before>/C<After> when all
585             its configured start-up commands have been invoked and they either failed or reported start-up
586             success. Note that this does includes C<ExecStartPost> (or
587             C<ExecStopPost> for the shutdown case).
588              
589             Note that those settings are independent of and orthogonal to the requirement dependencies as
590             configured by C<Requires>, C<Wants>, C<Requisite>,
591             or C<BindsTo>. It is a common pattern to include a unit name in both the
592             C<After> and C<Wants> options, in which case the unit listed will
593             be started before the unit that is configured with these options.
594              
595             Note that C<Before> dependencies on device units have no effect and are not
596             supported. Devices generally become available as a result of an external hotplug event, and systemd
597             creates the corresponding device unit without delay.',
598             'type' => 'list'
599             },
600             'OnFailure',
601             {
602             'description' => 'A space-separated list of one or more units that are activated when this unit enters
603             the C<failed> state. A service unit using C<Restart> enters the
604             failed state only after the start limits are reached.',
605             'type' => 'leaf',
606             'value_type' => 'uniline'
607             },
608             'OnSuccess',
609             {
610             'description' => 'A space-separated list of one or more units that are activated when this unit enters
611             the C<inactive> state.',
612             'type' => 'leaf',
613             'value_type' => 'uniline'
614             },
615             'PropagatesReloadTo',
616             {
617             'description' => 'A space-separated list of one or more units to which reload requests from this unit
618             shall be propagated to, or units from which reload requests shall be propagated to this unit,
619             respectively. Issuing a reload request on a unit will automatically also enqueue reload requests on
620             all units that are linked to it using these two settings.',
621             'type' => 'leaf',
622             'value_type' => 'uniline'
623             },
624             'ReloadPropagatedFrom',
625             {
626             'description' => 'A space-separated list of one or more units to which reload requests from this unit
627             shall be propagated to, or units from which reload requests shall be propagated to this unit,
628             respectively. Issuing a reload request on a unit will automatically also enqueue reload requests on
629             all units that are linked to it using these two settings.',
630             'type' => 'leaf',
631             'value_type' => 'uniline'
632             },
633             'PropagatesStopTo',
634             {
635             'description' => 'A space-separated list of one or more units to which stop requests from this unit
636             shall be propagated to, or units from which stop requests shall be propagated to this unit,
637             respectively. Issuing a stop request on a unit will automatically also enqueue stop requests on all
638             units that are linked to it using these two settings.',
639             'type' => 'leaf',
640             'value_type' => 'uniline'
641             },
642             'StopPropagatedFrom',
643             {
644             'description' => 'A space-separated list of one or more units to which stop requests from this unit
645             shall be propagated to, or units from which stop requests shall be propagated to this unit,
646             respectively. Issuing a stop request on a unit will automatically also enqueue stop requests on all
647             units that are linked to it using these two settings.',
648             'type' => 'leaf',
649             'value_type' => 'uniline'
650             },
651             'JoinsNamespaceOf',
652             {
653             'description' => 'For units that start processes (such as service units), lists one or more other units
654             whose network and/or temporary file namespace to join. This only applies to unit types which support
655             the C<PrivateNetwork>, C<NetworkNamespacePath>,
656             C<PrivateIPC>, C<IPCNamespacePath>, and
657             C<PrivateTmp> directives (see
658             L<systemd.exec(5)> for
659             details). If a unit that has this setting set is started, its processes will see the same
660             C</tmp/>, C</var/tmp/>, IPC namespace and network namespace as
661             one listed unit that is started. If multiple listed units are already started, it is not defined
662             which namespace is joined. Note that this setting only has an effect if
663             C<PrivateNetwork>/C<NetworkNamespacePath>,
664             C<PrivateIPC>/C<IPCNamespacePath> and/or
665             C<PrivateTmp> is enabled for both the unit that joins the namespace and the unit
666             whose namespace is joined.',
667             'type' => 'leaf',
668             'value_type' => 'uniline'
669             },
670             'RequiresMountsFor',
671             {
672             'description' => 'Takes a space-separated list of absolute
673             paths. Automatically adds dependencies of type
674             C<Requires> and C<After> for
675             all mount units required to access the specified path.
676              
677             Mount points marked with C<noauto> are not
678             mounted automatically through C<local-fs.target>,
679             but are still honored for the purposes of this option, i.e. they
680             will be pulled in by this unit.',
681             'type' => 'leaf',
682             'value_type' => 'uniline'
683             },
684             'OnFailureJobMode',
685             {
686             'description' => 'Takes a value of
687             C<fail>,
688             C<replace>,
689             C<replace-irreversibly>,
690             C<isolate>,
691             C<flush>,
692             C<ignore-dependencies> or
693             C<ignore-requirements>. Defaults to
694             C<replace>. Specifies how the units listed in
695             C<OnFailure> will be enqueued. See
696             L<systemctl(1)>\'s
697             C<--job-mode=> option for details on the
698             possible values. If this is set to C<isolate>,
699             only a single unit may be listed in
700             C<OnFailure>.',
701             'migrate_from' => {
702             'formula' => '$unit',
703             'variables' => {
704             'unit' => '- OnFailureIsolate'
705             }
706             },
707             'type' => 'leaf',
708             'value_type' => 'uniline'
709             },
710             'IgnoreOnIsolate',
711             {
712             'description' => 'Takes a boolean argument. If C<true>, this unit will not be stopped
713             when isolating another unit. Defaults to C<false> for service, target, socket, timer,
714             and path units, and C<true> for slice, scope, device, swap, mount, and automount
715             units.',
716             'type' => 'leaf',
717             'value_type' => 'boolean',
718             'write_as' => [
719             'no',
720             'yes'
721             ]
722             },
723             'StopWhenUnneeded',
724             {
725             'description' => 'Takes a boolean argument. If
726             C<true>, this unit will be stopped when it is no
727             longer used. Note that, in order to minimize the work to be
728             executed, systemd will not stop units by default unless they
729             are conflicting with other units, or the user explicitly
730             requested their shut down. If this option is set, a unit will
731             be automatically cleaned up if no other active unit requires
732             it. Defaults to C<false>.',
733             'type' => 'leaf',
734             'value_type' => 'boolean',
735             'write_as' => [
736             'no',
737             'yes'
738             ]
739             },
740             'RefuseManualStart',
741             {
742             'description' => 'Takes a boolean argument. If
743             C<true>, this unit can only be activated or
744             deactivated indirectly. In this case, explicit start-up or
745             termination requested by the user is denied, however if it is
746             started or stopped as a dependency of another unit, start-up
747             or termination will succeed. This is mostly a safety feature
748             to ensure that the user does not accidentally activate units
749             that are not intended to be activated explicitly, and not
750             accidentally deactivate units that are not intended to be
751             deactivated. These options default to
752             C<false>.',
753             'type' => 'leaf',
754             'value_type' => 'boolean',
755             'write_as' => [
756             'no',
757             'yes'
758             ]
759             },
760             'RefuseManualStop',
761             {
762             'description' => 'Takes a boolean argument. If
763             C<true>, this unit can only be activated or
764             deactivated indirectly. In this case, explicit start-up or
765             termination requested by the user is denied, however if it is
766             started or stopped as a dependency of another unit, start-up
767             or termination will succeed. This is mostly a safety feature
768             to ensure that the user does not accidentally activate units
769             that are not intended to be activated explicitly, and not
770             accidentally deactivate units that are not intended to be
771             deactivated. These options default to
772             C<false>.',
773             'type' => 'leaf',
774             'value_type' => 'boolean',
775             'write_as' => [
776             'no',
777             'yes'
778             ]
779             },
780             'AllowIsolate',
781             {
782             'description' => 'Takes a boolean argument. If
783             C<true>, this unit may be used with the
784             systemctl isolate command. Otherwise, this
785             will be refused. It probably is a good idea to leave this
786             disabled except for target units that shall be used similar to
787             runlevels in SysV init systems, just as a precaution to avoid
788             unusable system states. This option defaults to
789             C<false>.',
790             'type' => 'leaf',
791             'value_type' => 'boolean',
792             'write_as' => [
793             'no',
794             'yes'
795             ]
796             },
797             'DefaultDependencies',
798             {
799             'description' => 'Takes a boolean argument. If
800             C<yes>, (the default), a few default
801             dependencies will implicitly be created for the unit. The
802             actual dependencies created depend on the unit type. For
803             example, for service units, these dependencies ensure that the
804             service is started only after basic system initialization is
805             completed and is properly terminated on system shutdown. See
806             the respective man pages for details. Generally, only services
807             involved with early boot or late shutdown should set this
808             option to C<no>. It is highly recommended to
809             leave this option enabled for the majority of common units. If
810             set to C<no>, this option does not disable
811             all implicit dependencies, just non-essential
812             ones.',
813             'type' => 'leaf',
814             'value_type' => 'boolean',
815             'write_as' => [
816             'no',
817             'yes'
818             ]
819             },
820             'CollectMode',
821             {
822             'choice' => [
823             'inactive',
824             'inactive-or-failed'
825             ],
826             'description' => "Tweaks the \"garbage collection\" algorithm for this unit. Takes one of C<inactive>
827             or C<inactive-or-failed>. If set to C<inactive> the unit will be unloaded if it is
828             in the C<inactive> state and is not referenced by clients, jobs or other units \x{2014} however it
829             is not unloaded if it is in the C<failed> state. In C<failed> mode, failed
830             units are not unloaded until the user invoked systemctl reset-failed on them to reset the
831             C<failed> state, or an equivalent command. This behaviour is altered if this option is set to
832             C<inactive-or-failed>: in this case the unit is unloaded even if the unit is in a
833             C<failed> state, and thus an explicitly resetting of the C<failed> state is
834             not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed
835             resources, \x{2026}) are flushed out immediately after the unit completed, except for what is stored in the logging
836             subsystem. Defaults to C<inactive>.",
837             'type' => 'leaf',
838             'value_type' => 'enum'
839             },
840             'FailureActionExitStatus',
841             {
842             'description' => "Controls the exit status to propagate back to an invoking container manager (in case of a
843             system service) or service manager (in case of a user manager) when the
844             C<FailureAction>/C<SuccessAction> are set to C<exit> or
845             C<exit-force> and the action is triggered. By default the exit status of the main process of the
846             triggering unit (if this applies) is propagated. Takes a value in the range 0\x{2026}255 or the empty string to
847             request default behaviour.",
848             'type' => 'leaf',
849             'value_type' => 'uniline'
850             },
851             'SuccessActionExitStatus',
852             {
853             'description' => "Controls the exit status to propagate back to an invoking container manager (in case of a
854             system service) or service manager (in case of a user manager) when the
855             C<FailureAction>/C<SuccessAction> are set to C<exit> or
856             C<exit-force> and the action is triggered. By default the exit status of the main process of the
857             triggering unit (if this applies) is propagated. Takes a value in the range 0\x{2026}255 or the empty string to
858             request default behaviour.",
859             'type' => 'leaf',
860             'value_type' => 'uniline'
861             },
862             'JobTimeoutSec',
863             {
864             'description' => 'C<JobTimeoutSec> specifies a timeout for the whole job that starts
865             running when the job is queued. C<JobRunningTimeoutSec> specifies a timeout that
866             starts running when the queued job is actually started. If either limit is reached, the job will be
867             cancelled, the unit however will not change state or even enter the C<failed> mode.
868              
869             Both settings take a time span with the default unit of seconds, but other units may be
870             specified, see
871             L<systemd.time(5)>.
872             The default is C<infinity> (job timeouts disabled), except for device units where
873             C<JobRunningTimeoutSec> defaults to C<DefaultTimeoutStartSec>.
874              
875             Note: these timeouts are independent from any unit-specific timeouts (for example, the timeout
876             set with C<TimeoutStartSec> in service units). The job timeout has no effect on the
877             unit itself. Or in other words: unit-specific timeouts are useful to abort unit state changes, and
878             revert them. The job timeout set with this option however is useful to abort only the job waiting for
879             the unit state to change.',
880             'type' => 'leaf',
881             'value_type' => 'uniline'
882             },
883             'JobRunningTimeoutSec',
884             {
885             'description' => 'C<JobTimeoutSec> specifies a timeout for the whole job that starts
886             running when the job is queued. C<JobRunningTimeoutSec> specifies a timeout that
887             starts running when the queued job is actually started. If either limit is reached, the job will be
888             cancelled, the unit however will not change state or even enter the C<failed> mode.
889              
890             Both settings take a time span with the default unit of seconds, but other units may be
891             specified, see
892             L<systemd.time(5)>.
893             The default is C<infinity> (job timeouts disabled), except for device units where
894             C<JobRunningTimeoutSec> defaults to C<DefaultTimeoutStartSec>.
895              
896             Note: these timeouts are independent from any unit-specific timeouts (for example, the timeout
897             set with C<TimeoutStartSec> in service units). The job timeout has no effect on the
898             unit itself. Or in other words: unit-specific timeouts are useful to abort unit state changes, and
899             revert them. The job timeout set with this option however is useful to abort only the job waiting for
900             the unit state to change.',
901             'type' => 'leaf',
902             'value_type' => 'uniline'
903             },
904             'JobTimeoutAction',
905             {
906             'description' => 'C<JobTimeoutAction> optionally configures an additional action to
907             take when the timeout is hit, see description of C<JobTimeoutSec> and
908             C<JobRunningTimeoutSec> above. It takes the same values as
909             C<StartLimitAction>. Defaults to C<none>.
910              
911             C<JobTimeoutRebootArgument> configures an optional reboot string to pass to
912             the L<reboot(2)> system
913             call.',
914             'type' => 'leaf',
915             'value_type' => 'uniline'
916             },
917             'JobTimeoutRebootArgument',
918             {
919             'description' => 'C<JobTimeoutAction> optionally configures an additional action to
920             take when the timeout is hit, see description of C<JobTimeoutSec> and
921             C<JobRunningTimeoutSec> above. It takes the same values as
922             C<StartLimitAction>. Defaults to C<none>.
923              
924             C<JobTimeoutRebootArgument> configures an optional reboot string to pass to
925             the L<reboot(2)> system
926             call.',
927             'type' => 'leaf',
928             'value_type' => 'uniline'
929             },
930             'StartLimitAction',
931             {
932             'choice' => [
933             'none',
934             'reboot',
935             'reboot-force',
936             'reboot-immediate',
937             'poweroff',
938             'poweroff-force',
939             'poweroff-immediate',
940             'exit',
941             'exit-force'
942             ],
943             'description' => 'Configure an additional action to take if the rate limit configured with
944             C<StartLimitIntervalSec> and C<StartLimitBurst> is hit. Takes the same
945             values as the C<FailureAction>/C<SuccessAction> settings. If
946             C<none> is set, hitting the rate limit will trigger no action except that
947             the start will not be permitted. Defaults to C<none>.',
948             'type' => 'leaf',
949             'value_type' => 'enum'
950             },
951             'SourcePath',
952             {
953             'description' => 'A path to a configuration file this unit has
954             been generated from. This is primarily useful for
955             implementation of generator tools that convert configuration
956             from an external configuration file format into native unit
957             files. This functionality should not be used in normal
958             units.',
959             'type' => 'leaf',
960             'value_type' => 'uniline'
961             },
962             'ConditionArchitecture',
963             {
964             'cargo' => {
965             'choice' => [
966             'x86',
967             'x86-64',
968             'ppc',
969             'ppc-le',
970             'ppc64',
971             'ppc64-le',
972             'ia64',
973             'parisc',
974             'parisc64',
975             's390',
976             's390x',
977             'sparc',
978             'sparc64',
979             'mips',
980             'mips-le',
981             'mips64',
982             'mips64-le',
983             'alpha',
984             'arm',
985             'arm-be',
986             'arm64',
987             'arm64-be',
988             'sh',
989             'sh64',
990             'm68k',
991             'tilegx',
992             'cris',
993             'arc',
994             'arc-be',
995             'native'
996             ],
997             'type' => 'leaf',
998             'value_type' => 'enum'
999             },
1000             'description' => 'Check whether the system is running on a specific architecture. Takes one of
1001             C<x86>,
1002             C<x86-64>,
1003             C<ppc>,
1004             C<ppc-le>,
1005             C<ppc64>,
1006             C<ppc64-le>,
1007             C<ia64>,
1008             C<parisc>,
1009             C<parisc64>,
1010             C<s390>,
1011             C<s390x>,
1012             C<sparc>,
1013             C<sparc64>,
1014             C<mips>,
1015             C<mips-le>,
1016             C<mips64>,
1017             C<mips64-le>,
1018             C<alpha>,
1019             C<arm>,
1020             C<arm-be>,
1021             C<arm64>,
1022             C<arm64-be>,
1023             C<sh>,
1024             C<sh64>,
1025             C<m68k>,
1026             C<tilegx>,
1027             C<cris>,
1028             C<arc>,
1029             C<arc-be>, or
1030             C<native>.
1031              
1032             The architecture is determined from the information returned by
1033             L<uname(2)>
1034             and is thus subject to
1035             L<personality(2)>.
1036             Note that a C<Personality> setting in the same unit file has no effect on this
1037             condition. A special architecture name C<native> is mapped to the architecture the
1038             system manager itself is compiled for. The test may be negated by prepending an exclamation
1039             mark.',
1040             'type' => 'list'
1041             },
1042             'ConditionFirmware',
1043             {
1044             'cargo' => {
1045             'type' => 'leaf',
1046             'value_type' => 'uniline'
1047             },
1048             'description' => 'Check whether the system\'s firmware is of a certain type. Possible values are:
1049             C<uefi> (for systems with EFI),
1050             C<device-tree> (for systems with a device tree) and
1051             C<device-tree-compatible(xyz)> (for systems with a device tree that is compatible to C<xyz>).',
1052             'type' => 'list'
1053             },
1054             'ConditionVirtualization',
1055             {
1056             'cargo' => {
1057             'type' => 'leaf',
1058             'value_type' => 'uniline'
1059             },
1060             'description' => 'Check whether the system is executed in a virtualized environment and optionally
1061             test whether it is a specific implementation. Takes either boolean value to check if being executed
1062             in any virtualized environment, or one of
1063             C<vm> and
1064             C<container> to test against a generic type of virtualization solution, or one of
1065             C<qemu>,
1066             C<kvm>,
1067             C<amazon>,
1068             C<zvm>,
1069             C<vmware>,
1070             C<microsoft>,
1071             C<oracle>,
1072             C<powervm>,
1073             C<xen>,
1074             C<bochs>,
1075             C<uml>,
1076             C<bhyve>,
1077             C<qnx>,
1078             C<openvz>,
1079             C<lxc>,
1080             C<lxc-libvirt>,
1081             C<systemd-nspawn>,
1082             C<docker>,
1083             C<podman>,
1084             C<rkt>,
1085             C<wsl>,
1086             C<proot>,
1087             C<pouch>,
1088             C<acrn> to test
1089             against a specific implementation, or
1090             C<private-users> to check whether we are running in a user namespace. See
1091             L<systemd-detect-virt(1)>
1092             for a full list of known virtualization technologies and their identifiers. If multiple
1093             virtualization technologies are nested, only the innermost is considered. The test may be negated
1094             by prepending an exclamation mark.',
1095             'type' => 'list'
1096             },
1097             'ConditionHost',
1098             {
1099             'cargo' => {
1100             'type' => 'leaf',
1101             'value_type' => 'uniline'
1102             },
1103             'description' => 'C<ConditionHost> may be used to match against the hostname or
1104             machine ID of the host. This either takes a hostname string (optionally with shell style globs)
1105             which is tested against the locally set hostname as returned by
1106             L<gethostname(2)>, or
1107             a machine ID formatted as string (see
1108             L<machine-id(5)>).
1109             The test may be negated by prepending an exclamation mark.',
1110             'type' => 'list'
1111             },
1112             'ConditionKernelCommandLine',
1113             {
1114             'cargo' => {
1115             'type' => 'leaf',
1116             'value_type' => 'uniline'
1117             },
1118             'description' => "C<ConditionKernelCommandLine> may be used to check whether a
1119             specific kernel command line option is set (or if prefixed with the exclamation mark \x{2014} unset). The
1120             argument must either be a single word, or an assignment (i.e. two words, separated by
1121             C<=>). In the former case the kernel command line is searched for the word
1122             appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is
1123             looked for with right and left hand side matching. This operates on the kernel command line
1124             communicated to userspace via C</proc/cmdline>, except when the service manager
1125             is invoked as payload of a container manager, in which case the command line of C<PID
1126             1> is used instead (i.e. C</proc/1/cmdline>).",
1127             'type' => 'list'
1128             },
1129             'ConditionKernelVersion',
1130             {
1131             'cargo' => {
1132             'type' => 'leaf',
1133             'value_type' => 'uniline'
1134             },
1135             'description' => 'C<ConditionKernelVersion> may be used to check whether the kernel
1136             version (as reported by uname -r) matches a certain expression (or if prefixed
1137             with the exclamation mark does not match it). The argument must be a list of (potentially quoted)
1138             expressions. For each of the expressions, if it starts with one of C<<>,
1139             C<<=>, C<=>, C<!=>, C<>=>,
1140             C<>> a relative version comparison is done, otherwise the specified string is
1141             matched with shell-style globs.
1142              
1143             Note that using the kernel version string is an unreliable way to determine which features
1144             are supported by a kernel, because of the widespread practice of backporting drivers, features, and
1145             fixes from newer upstream kernels into older versions provided by distributions. Hence, this check
1146             is inherently unportable and should not be used for units which may be used on different
1147             distributions.',
1148             'type' => 'list'
1149             },
1150             'ConditionEnvironment',
1151             {
1152             'cargo' => {
1153             'type' => 'leaf',
1154             'value_type' => 'uniline'
1155             },
1156             'description' => "C<ConditionEnvironment> may be used to check whether a specific
1157             environment variable is set (or if prefixed with the exclamation mark \x{2014} unset) in the service
1158             manager's environment block.
1159             The argument may be a single word, to check if the variable with this name is defined in the
1160             environment block, or an assignment
1161             (C<name=value>), to check if
1162             the variable with this exact value is defined. Note that the environment block of the service
1163             manager itself is checked, i.e. not any variables defined with C<Environment> or
1164             C<EnvironmentFile>, as described above. This is particularly useful when the
1165             service manager runs inside a containerized environment or as per-user service manager, in order to
1166             check for variables passed in by the enclosing container manager or PAM.",
1167             'type' => 'list'
1168             },
1169             'ConditionSecurity',
1170             {
1171             'cargo' => {
1172             'type' => 'leaf',
1173             'value_type' => 'uniline'
1174             },
1175             'description' => 'C<ConditionSecurity> may be used to check whether the given
1176             security technology is enabled on the system. Currently, the recognized values are
1177             C<selinux>, C<apparmor>, C<tomoyo>,
1178             C<ima>, C<smack>, C<audit>,
1179             C<uefi-secureboot> and C<tpm2>. The test may be negated by prepending
1180             an exclamation mark.',
1181             'type' => 'list'
1182             },
1183             'ConditionCapability',
1184             {
1185             'cargo' => {
1186             'type' => 'leaf',
1187             'value_type' => 'uniline'
1188             },
1189             'description' => 'Check whether the given capability exists in the capability bounding set of the
1190             service manager (i.e. this does not check whether capability is actually available in the permitted
1191             or effective sets, see
1192             L<capabilities(7)>
1193             for details). Pass a capability name such as C<CAP_MKNOD>, possibly prefixed with
1194             an exclamation mark to negate the check.',
1195             'type' => 'list'
1196             },
1197             'ConditionACPower',
1198             {
1199             'cargo' => {
1200             'type' => 'leaf',
1201             'value_type' => 'uniline'
1202             },
1203             'description' => 'Check whether the system has AC power, or is exclusively battery powered at the
1204             time of activation of the unit. This takes a boolean argument. If set to C<true>,
1205             the condition will hold only if at least one AC connector of the system is connected to a power
1206             source, or if no AC connectors are known. Conversely, if set to C<false>, the
1207             condition will hold only if there is at least one AC connector known and all AC connectors are
1208             disconnected from a power source.',
1209             'type' => 'list'
1210             },
1211             'ConditionNeedsUpdate',
1212             {
1213             'cargo' => {
1214             'choice' => [
1215             '/var/',
1216             '/etc/',
1217             '!/var/',
1218             '!/etc/'
1219             ],
1220             'type' => 'leaf',
1221             'value_type' => 'enum'
1222             },
1223             'description' => 'Takes one of C</var/> or C</etc/> as argument,
1224             possibly prefixed with a C<!> (to invert the condition). This condition may be
1225             used to conditionalize units on whether the specified directory requires an update because
1226             C</usr/>\'s modification time is newer than the stamp file
1227             C<.updated> in the specified directory. This is useful to implement offline
1228             updates of the vendor operating system resources in C</usr/> that require updating
1229             of C</etc/> or C</var/> on the next following boot. Units making
1230             use of this condition should order themselves before
1231             L<systemd-update-done.service(8)>,
1232             to make sure they run before the stamp file\'s modification time gets reset indicating a completed
1233             update.
1234              
1235             If the C<systemd.condition-needs-update=> option is specified on the kernel
1236             command line (taking a boolean), it will override the result of this condition check, taking
1237             precedence over any file modification time checks. If the kernel command line option is used,
1238             C<systemd-update-done.service> will not have immediate effect on any following
1239             C<ConditionNeedsUpdate> checks, until the system is rebooted where the kernel
1240             command line option is not specified anymore.
1241              
1242             Note that to make this scheme effective, the timestamp of C</usr/> should
1243             be explicitly updated after its contents are modified. The kernel will automatically update
1244             modification timestamp on a directory only when immediate children of a directory are modified; an
1245             modification of nested files will not automatically result in mtime of C</usr/>
1246             being updated.
1247              
1248             Also note that if the update method includes a call to execute appropriate post-update steps
1249             itself, it should not touch the timestamp of C</usr/>. In a typical distribution
1250             packaging scheme, packages will do any required update steps as part of the installation or
1251             upgrade, to make package contents immediately usable. C<ConditionNeedsUpdate>
1252             should be used with other update mechanisms where such an immediate update does not
1253             happen.',
1254             'type' => 'list'
1255             },
1256             'ConditionFirstBoot',
1257             {
1258             'cargo' => {
1259             'type' => 'leaf',
1260             'value_type' => 'boolean',
1261             'write_as' => [
1262             'no',
1263             'yes'
1264             ]
1265             },
1266             'description' => 'Takes a boolean argument. This condition may be used to conditionalize units on
1267             whether the system is booting up for the first time. This roughly means that C</etc/>
1268             is unpopulated (for details, see "First Boot Semantics" in
1269             L<machine-id(5)>).
1270             This may be used to populate C</etc/> on the first boot after factory reset, or
1271             when a new system instance boots up for the first time.
1272              
1273             For robustness, units with C<ConditionFirstBoot=yes> should order themselves
1274             before C<first-boot-complete.target> and pull in this passive target with
1275             C<Wants>. This ensures that in a case of an aborted first boot, these units will
1276             be re-run during the next system startup.
1277              
1278             If the C<systemd.condition-first-boot=> option is specified on the kernel
1279             command line (taking a boolean), it will override the result of this condition check, taking
1280             precedence over C</etc/machine-id> existence checks.',
1281             'type' => 'list'
1282             },
1283             'ConditionPathExists',
1284             {
1285             'cargo' => {
1286             'type' => 'leaf',
1287             'value_type' => 'uniline'
1288             },
1289             'description' => 'Check for the existence of a file. If the specified absolute path name does not exist,
1290             the condition will fail. If the absolute path name passed to
1291             C<ConditionPathExists> is prefixed with an exclamation mark
1292             (C<!>), the test is negated, and the unit is only started if the path does not
1293             exist.',
1294             'type' => 'list'
1295             },
1296             'ConditionPathExistsGlob',
1297             {
1298             'cargo' => {
1299             'type' => 'leaf',
1300             'value_type' => 'uniline'
1301             },
1302             'description' => 'C<ConditionPathExistsGlob> is similar to
1303             C<ConditionPathExists>, but checks for the existence of at least one file or
1304             directory matching the specified globbing pattern.',
1305             'type' => 'list'
1306             },
1307             'ConditionPathIsDirectory',
1308             {
1309             'cargo' => {
1310             'type' => 'leaf',
1311             'value_type' => 'uniline'
1312             },
1313             'description' => 'C<ConditionPathIsDirectory> is similar to
1314             C<ConditionPathExists> but verifies that a certain path exists and is a
1315             directory.',
1316             'type' => 'list'
1317             },
1318             'ConditionPathIsSymbolicLink',
1319             {
1320             'cargo' => {
1321             'type' => 'leaf',
1322             'value_type' => 'uniline'
1323             },
1324             'description' => 'C<ConditionPathIsSymbolicLink> is similar to
1325             C<ConditionPathExists> but verifies that a certain path exists and is a symbolic
1326             link.',
1327             'type' => 'list'
1328             },
1329             'ConditionPathIsMountPoint',
1330             {
1331             'cargo' => {
1332             'type' => 'leaf',
1333             'value_type' => 'uniline'
1334             },
1335             'description' => 'C<ConditionPathIsMountPoint> is similar to
1336             C<ConditionPathExists> but verifies that a certain path exists and is a mount
1337             point.',
1338             'type' => 'list'
1339             },
1340             'ConditionPathIsReadWrite',
1341             {
1342             'cargo' => {
1343             'type' => 'leaf',
1344             'value_type' => 'uniline'
1345             },
1346             'description' => 'C<ConditionPathIsReadWrite> is similar to
1347             C<ConditionPathExists> but verifies that the underlying file system is readable
1348             and writable (i.e. not mounted read-only).',
1349             'type' => 'list'
1350             },
1351             'ConditionPathIsEncrypted',
1352             {
1353             'cargo' => {
1354             'type' => 'leaf',
1355             'value_type' => 'uniline'
1356             },
1357             'description' => 'C<ConditionPathIsEncrypted> is similar to
1358             C<ConditionPathExists> but verifies that the underlying file system\'s backing
1359             block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4
1360             per-directory encryption, and only detects block level encryption. Moreover, if the specified path
1361             resides on a file system on top of a loopback block device, only encryption above the loopback device is
1362             detected. It is not detected whether the file system backing the loopback block device is encrypted.',
1363             'type' => 'list'
1364             },
1365             'ConditionDirectoryNotEmpty',
1366             {
1367             'cargo' => {
1368             'type' => 'leaf',
1369             'value_type' => 'uniline'
1370             },
1371             'description' => 'C<ConditionDirectoryNotEmpty> is similar to
1372             C<ConditionPathExists> but verifies that a certain path exists and is a non-empty
1373             directory.',
1374             'type' => 'list'
1375             },
1376             'ConditionFileNotEmpty',
1377             {
1378             'cargo' => {
1379             'type' => 'leaf',
1380             'value_type' => 'uniline'
1381             },
1382             'description' => 'C<ConditionFileNotEmpty> is similar to
1383             C<ConditionPathExists> but verifies that a certain path exists and refers to a
1384             regular file with a non-zero size.',
1385             'type' => 'list'
1386             },
1387             'ConditionFileIsExecutable',
1388             {
1389             'cargo' => {
1390             'type' => 'leaf',
1391             'value_type' => 'uniline'
1392             },
1393             'description' => 'C<ConditionFileIsExecutable> is similar to
1394             C<ConditionPathExists> but verifies that a certain path exists, is a regular file,
1395             and marked executable.',
1396             'type' => 'list'
1397             },
1398             'ConditionUser',
1399             {
1400             'cargo' => {
1401             'type' => 'leaf',
1402             'value_type' => 'uniline'
1403             },
1404             'description' => 'C<ConditionUser> takes a numeric C<UID>, a UNIX
1405             user name, or the special value C<@system>. This condition may be used to check
1406             whether the service manager is running as the given user. The special value
1407             C<@system> can be used to check if the user id is within the system user
1408             range. This option is not useful for system services, as the system manager exclusively runs as the
1409             root user, and thus the test result is constant.',
1410             'type' => 'list'
1411             },
1412             'ConditionGroup',
1413             {
1414             'cargo' => {
1415             'type' => 'leaf',
1416             'value_type' => 'uniline'
1417             },
1418             'description' => 'C<ConditionGroup> is similar to C<ConditionUser>
1419             but verifies that the service manager\'s real or effective group, or any of its auxiliary groups,
1420             match the specified group or GID. This setting does not support the special value
1421             C<@system>.',
1422             'type' => 'list'
1423             },
1424             'ConditionControlGroupController',
1425             {
1426             'cargo' => {
1427             'type' => 'leaf',
1428             'value_type' => 'uniline'
1429             },
1430             'description' => 'Check whether given cgroup controllers (e.g. C<cpu>) are available
1431             for use on the system or whether the legacy v1 cgroup or the modern v2 cgroup hierarchy is used.
1432              
1433             Multiple controllers may be passed with a space separating them; in this case the condition
1434             will only pass if all listed controllers are available for use. Controllers unknown to systemd are
1435             ignored. Valid controllers are C<cpu>, C<cpuacct>,
1436             C<io>, C<blkio>, C<memory>,
1437             C<devices>, and C<pids>. Even if available in the kernel, a
1438             particular controller may not be available if it was disabled on the kernel command line with
1439             C<cgroup_disable=controller>.
1440              
1441             Alternatively, two special strings C<v1> and C<v2> may be
1442             specified (without any controller names). C<v2> will pass if the unified v2 cgroup
1443             hierarchy is used, and C<v1> will pass if the legacy v1 hierarchy or the hybrid
1444             hierarchy are used (see the discussion of C<systemd.unified_cgroup_hierarchy> and
1445             C<systemd.legacy_systemd_cgroup_controller> in
1446             L<systemd.service(5)>
1447             for more information).',
1448             'type' => 'list'
1449             },
1450             'ConditionMemory',
1451             {
1452             'cargo' => {
1453             'type' => 'leaf',
1454             'value_type' => 'uniline'
1455             },
1456             'description' => 'Verify that the specified amount of system memory is available to the current
1457             system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator
1458             C<<>, C<<=>, C<=>, C<!=>,
1459             C<>=>, C<>>. On bare-metal systems compares the amount of
1460             physical memory in the system with the specified size, adhering to the specified comparison
1461             operator. In containers compares the amount of memory assigned to the container instead.',
1462             'type' => 'list'
1463             },
1464             'ConditionCPUs',
1465             {
1466             'cargo' => {
1467             'type' => 'leaf',
1468             'value_type' => 'uniline'
1469             },
1470             'description' => 'Verify that the specified number of CPUs is available to the current system. Takes
1471             a number of CPUs as argument, optionally prefixed with a comparison operator
1472             C<<>, C<<=>, C<=>, C<!=>,
1473             C<>=>, C<>>. Compares the number of CPUs in the CPU affinity
1474             mask configured of the service manager itself with the specified number, adhering to the specified
1475             comparison operator. On physical systems the number of CPUs in the affinity mask of the service
1476             manager usually matches the number of physical CPUs, but in special and virtual environments might
1477             differ. In particular, in containers the affinity mask usually matches the number of CPUs assigned
1478             to the container and not the physically available ones.',
1479             'type' => 'list'
1480             },
1481             'ConditionCPUFeature',
1482             {
1483             'cargo' => {
1484             'type' => 'leaf',
1485             'value_type' => 'uniline'
1486             },
1487             'description' => 'Verify that a given CPU feature is available via the C<CPUID>
1488             instruction. This condition only does something on i386 and x86-64 processors. On other
1489             processors it is assumed that the CPU does not support the given feature. It checks the leaves
1490             C<1>, C<7>, C<0x80000001>, and
1491             C<0x80000007>. Valid values are:
1492             C<fpu>,
1493             C<vme>,
1494             C<de>,
1495             C<pse>,
1496             C<tsc>,
1497             C<msr>,
1498             C<pae>,
1499             C<mce>,
1500             C<cx8>,
1501             C<apic>,
1502             C<sep>,
1503             C<mtrr>,
1504             C<pge>,
1505             C<mca>,
1506             C<cmov>,
1507             C<pat>,
1508             C<pse36>,
1509             C<clflush>,
1510             C<mmx>,
1511             C<fxsr>,
1512             C<sse>,
1513             C<sse2>,
1514             C<ht>,
1515             C<pni>,
1516             C<pclmul>,
1517             C<monitor>,
1518             C<ssse3>,
1519             C<fma3>,
1520             C<cx16>,
1521             C<sse4_1>,
1522             C<sse4_2>,
1523             C<movbe>,
1524             C<popcnt>,
1525             C<aes>,
1526             C<xsave>,
1527             C<osxsave>,
1528             C<avx>,
1529             C<f16c>,
1530             C<rdrand>,
1531             C<bmi1>,
1532             C<avx2>,
1533             C<bmi2>,
1534             C<rdseed>,
1535             C<adx>,
1536             C<sha_ni>,
1537             C<syscall>,
1538             C<rdtscp>,
1539             C<lm>,
1540             C<lahf_lm>,
1541             C<abm>,
1542             C<constant_tsc>.',
1543             'type' => 'list'
1544             },
1545             'ConditionOSRelease',
1546             {
1547             'cargo' => {
1548             'type' => 'leaf',
1549             'value_type' => 'uniline'
1550             },
1551             'description' => 'Verify that a specific C<key=value> pair is set in the host\'s
1552             L<os-release(5)>.
1553              
1554             Other than exact matching with C<=>, and C<!=>, relative
1555             comparisons are supported for versioned parameters (e.g. C<VERSION_ID>). The
1556             comparator can be one of C<<>, C<<=>, C<=>,
1557             C<!=>, C<>=> and C<>>.',
1558             'type' => 'list'
1559             },
1560             'ConditionMemoryPressure',
1561             {
1562             'cargo' => {
1563             'type' => 'leaf',
1564             'value_type' => 'uniline'
1565             },
1566             'description' => 'Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold.
1567             This setting takes a threshold value as argument. It can be specified as a simple percentage value,
1568             suffixed with C<%>, in which case the pressure will be measured as an average over the last
1569             five minutes before the attempt to start the unit is performed.
1570             Alternatively, the average timespan can also be specified using C</> as a separator, for
1571             example: C<10%/1min>. The supported timespans match what the kernel provides, and are
1572             limited to C<10sec>, C<1min> and C<5min>. The
1573             C<full> PSI will be checked first, and if not found C<some> will be
1574             checked. For more details, see the documentation on L<PSI (Pressure Stall Information)
1575             |https://www.kernel.org/doc/html/latest/accounting/psi.html>.
1576              
1577             Optionally, the threshold value can be prefixed with the slice unit under which the pressure will be checked,
1578             followed by a C<:>. If the slice unit is not specified, the overall system pressure will be measured,
1579             instead of a particular cgroup\'s.',
1580             'type' => 'list'
1581             },
1582             'ConditionCPUPressure',
1583             {
1584             'cargo' => {
1585             'type' => 'leaf',
1586             'value_type' => 'uniline'
1587             },
1588             'description' => 'Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold.
1589             This setting takes a threshold value as argument. It can be specified as a simple percentage value,
1590             suffixed with C<%>, in which case the pressure will be measured as an average over the last
1591             five minutes before the attempt to start the unit is performed.
1592             Alternatively, the average timespan can also be specified using C</> as a separator, for
1593             example: C<10%/1min>. The supported timespans match what the kernel provides, and are
1594             limited to C<10sec>, C<1min> and C<5min>. The
1595             C<full> PSI will be checked first, and if not found C<some> will be
1596             checked. For more details, see the documentation on L<PSI (Pressure Stall Information)
1597             |https://www.kernel.org/doc/html/latest/accounting/psi.html>.
1598              
1599             Optionally, the threshold value can be prefixed with the slice unit under which the pressure will be checked,
1600             followed by a C<:>. If the slice unit is not specified, the overall system pressure will be measured,
1601             instead of a particular cgroup\'s.',
1602             'type' => 'list'
1603             },
1604             'ConditionIOPressure',
1605             {
1606             'cargo' => {
1607             'type' => 'leaf',
1608             'value_type' => 'uniline'
1609             },
1610             'description' => 'Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold.
1611             This setting takes a threshold value as argument. It can be specified as a simple percentage value,
1612             suffixed with C<%>, in which case the pressure will be measured as an average over the last
1613             five minutes before the attempt to start the unit is performed.
1614             Alternatively, the average timespan can also be specified using C</> as a separator, for
1615             example: C<10%/1min>. The supported timespans match what the kernel provides, and are
1616             limited to C<10sec>, C<1min> and C<5min>. The
1617             C<full> PSI will be checked first, and if not found C<some> will be
1618             checked. For more details, see the documentation on L<PSI (Pressure Stall Information)
1619             |https://www.kernel.org/doc/html/latest/accounting/psi.html>.
1620              
1621             Optionally, the threshold value can be prefixed with the slice unit under which the pressure will be checked,
1622             followed by a C<:>. If the slice unit is not specified, the overall system pressure will be measured,
1623             instead of a particular cgroup\'s.',
1624             'type' => 'list'
1625             },
1626             'AssertArchitecture',
1627             {
1628             'description' => "Similar to the C<ConditionArchitecture>,
1629             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1630             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1631             assertion setting that is not met results in failure of the start job (which means this is logged
1632             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1633             C<failed> state (or in fact result in any state change of the unit), it affects
1634             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1635             requirements are not met, and when this is something the administrator or user should look
1636             into.",
1637             'type' => 'leaf',
1638             'value_type' => 'uniline'
1639             },
1640             'AssertVirtualization',
1641             {
1642             'description' => "Similar to the C<ConditionArchitecture>,
1643             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1644             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1645             assertion setting that is not met results in failure of the start job (which means this is logged
1646             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1647             C<failed> state (or in fact result in any state change of the unit), it affects
1648             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1649             requirements are not met, and when this is something the administrator or user should look
1650             into.",
1651             'type' => 'leaf',
1652             'value_type' => 'uniline'
1653             },
1654             'AssertHost',
1655             {
1656             'description' => "Similar to the C<ConditionArchitecture>,
1657             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1658             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1659             assertion setting that is not met results in failure of the start job (which means this is logged
1660             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1661             C<failed> state (or in fact result in any state change of the unit), it affects
1662             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1663             requirements are not met, and when this is something the administrator or user should look
1664             into.",
1665             'type' => 'leaf',
1666             'value_type' => 'uniline'
1667             },
1668             'AssertKernelCommandLine',
1669             {
1670             'description' => "Similar to the C<ConditionArchitecture>,
1671             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1672             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1673             assertion setting that is not met results in failure of the start job (which means this is logged
1674             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1675             C<failed> state (or in fact result in any state change of the unit), it affects
1676             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1677             requirements are not met, and when this is something the administrator or user should look
1678             into.",
1679             'type' => 'leaf',
1680             'value_type' => 'uniline'
1681             },
1682             'AssertKernelVersion',
1683             {
1684             'description' => "Similar to the C<ConditionArchitecture>,
1685             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1686             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1687             assertion setting that is not met results in failure of the start job (which means this is logged
1688             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1689             C<failed> state (or in fact result in any state change of the unit), it affects
1690             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1691             requirements are not met, and when this is something the administrator or user should look
1692             into.",
1693             'type' => 'leaf',
1694             'value_type' => 'uniline'
1695             },
1696             'AssertEnvironment',
1697             {
1698             'description' => "Similar to the C<ConditionArchitecture>,
1699             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1700             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1701             assertion setting that is not met results in failure of the start job (which means this is logged
1702             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1703             C<failed> state (or in fact result in any state change of the unit), it affects
1704             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1705             requirements are not met, and when this is something the administrator or user should look
1706             into.",
1707             'type' => 'leaf',
1708             'value_type' => 'uniline'
1709             },
1710             'AssertSecurity',
1711             {
1712             'description' => "Similar to the C<ConditionArchitecture>,
1713             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1714             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1715             assertion setting that is not met results in failure of the start job (which means this is logged
1716             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1717             C<failed> state (or in fact result in any state change of the unit), it affects
1718             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1719             requirements are not met, and when this is something the administrator or user should look
1720             into.",
1721             'type' => 'leaf',
1722             'value_type' => 'uniline'
1723             },
1724             'AssertCapability',
1725             {
1726             'description' => "Similar to the C<ConditionArchitecture>,
1727             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1728             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1729             assertion setting that is not met results in failure of the start job (which means this is logged
1730             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1731             C<failed> state (or in fact result in any state change of the unit), it affects
1732             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1733             requirements are not met, and when this is something the administrator or user should look
1734             into.",
1735             'type' => 'leaf',
1736             'value_type' => 'uniline'
1737             },
1738             'AssertACPower',
1739             {
1740             'description' => "Similar to the C<ConditionArchitecture>,
1741             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1742             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1743             assertion setting that is not met results in failure of the start job (which means this is logged
1744             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1745             C<failed> state (or in fact result in any state change of the unit), it affects
1746             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1747             requirements are not met, and when this is something the administrator or user should look
1748             into.",
1749             'type' => 'leaf',
1750             'value_type' => 'uniline'
1751             },
1752             'AssertNeedsUpdate',
1753             {
1754             'description' => "Similar to the C<ConditionArchitecture>,
1755             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1756             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1757             assertion setting that is not met results in failure of the start job (which means this is logged
1758             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1759             C<failed> state (or in fact result in any state change of the unit), it affects
1760             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1761             requirements are not met, and when this is something the administrator or user should look
1762             into.",
1763             'type' => 'leaf',
1764             'value_type' => 'uniline'
1765             },
1766             'AssertFirstBoot',
1767             {
1768             'description' => "Similar to the C<ConditionArchitecture>,
1769             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1770             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1771             assertion setting that is not met results in failure of the start job (which means this is logged
1772             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1773             C<failed> state (or in fact result in any state change of the unit), it affects
1774             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1775             requirements are not met, and when this is something the administrator or user should look
1776             into.",
1777             'type' => 'leaf',
1778             'value_type' => 'uniline'
1779             },
1780             'AssertPathExists',
1781             {
1782             'description' => "Similar to the C<ConditionArchitecture>,
1783             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1784             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1785             assertion setting that is not met results in failure of the start job (which means this is logged
1786             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1787             C<failed> state (or in fact result in any state change of the unit), it affects
1788             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1789             requirements are not met, and when this is something the administrator or user should look
1790             into.",
1791             'type' => 'leaf',
1792             'value_type' => 'uniline'
1793             },
1794             'AssertPathExistsGlob',
1795             {
1796             'description' => "Similar to the C<ConditionArchitecture>,
1797             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1798             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1799             assertion setting that is not met results in failure of the start job (which means this is logged
1800             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1801             C<failed> state (or in fact result in any state change of the unit), it affects
1802             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1803             requirements are not met, and when this is something the administrator or user should look
1804             into.",
1805             'type' => 'leaf',
1806             'value_type' => 'uniline'
1807             },
1808             'AssertPathIsDirectory',
1809             {
1810             'description' => "Similar to the C<ConditionArchitecture>,
1811             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1812             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1813             assertion setting that is not met results in failure of the start job (which means this is logged
1814             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1815             C<failed> state (or in fact result in any state change of the unit), it affects
1816             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1817             requirements are not met, and when this is something the administrator or user should look
1818             into.",
1819             'type' => 'leaf',
1820             'value_type' => 'uniline'
1821             },
1822             'AssertPathIsSymbolicLink',
1823             {
1824             'description' => "Similar to the C<ConditionArchitecture>,
1825             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1826             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1827             assertion setting that is not met results in failure of the start job (which means this is logged
1828             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1829             C<failed> state (or in fact result in any state change of the unit), it affects
1830             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1831             requirements are not met, and when this is something the administrator or user should look
1832             into.",
1833             'type' => 'leaf',
1834             'value_type' => 'uniline'
1835             },
1836             'AssertPathIsMountPoint',
1837             {
1838             'description' => "Similar to the C<ConditionArchitecture>,
1839             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1840             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1841             assertion setting that is not met results in failure of the start job (which means this is logged
1842             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1843             C<failed> state (or in fact result in any state change of the unit), it affects
1844             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1845             requirements are not met, and when this is something the administrator or user should look
1846             into.",
1847             'type' => 'leaf',
1848             'value_type' => 'uniline'
1849             },
1850             'AssertPathIsReadWrite',
1851             {
1852             'description' => "Similar to the C<ConditionArchitecture>,
1853             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1854             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1855             assertion setting that is not met results in failure of the start job (which means this is logged
1856             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1857             C<failed> state (or in fact result in any state change of the unit), it affects
1858             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1859             requirements are not met, and when this is something the administrator or user should look
1860             into.",
1861             'type' => 'leaf',
1862             'value_type' => 'uniline'
1863             },
1864             'AssertPathIsEncrypted',
1865             {
1866             'description' => "Similar to the C<ConditionArchitecture>,
1867             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1868             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1869             assertion setting that is not met results in failure of the start job (which means this is logged
1870             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1871             C<failed> state (or in fact result in any state change of the unit), it affects
1872             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1873             requirements are not met, and when this is something the administrator or user should look
1874             into.",
1875             'type' => 'leaf',
1876             'value_type' => 'uniline'
1877             },
1878             'AssertDirectoryNotEmpty',
1879             {
1880             'description' => "Similar to the C<ConditionArchitecture>,
1881             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1882             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1883             assertion setting that is not met results in failure of the start job (which means this is logged
1884             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1885             C<failed> state (or in fact result in any state change of the unit), it affects
1886             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1887             requirements are not met, and when this is something the administrator or user should look
1888             into.",
1889             'type' => 'leaf',
1890             'value_type' => 'uniline'
1891             },
1892             'AssertFileNotEmpty',
1893             {
1894             'description' => "Similar to the C<ConditionArchitecture>,
1895             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1896             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1897             assertion setting that is not met results in failure of the start job (which means this is logged
1898             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1899             C<failed> state (or in fact result in any state change of the unit), it affects
1900             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1901             requirements are not met, and when this is something the administrator or user should look
1902             into.",
1903             'type' => 'leaf',
1904             'value_type' => 'uniline'
1905             },
1906             'AssertFileIsExecutable',
1907             {
1908             'description' => "Similar to the C<ConditionArchitecture>,
1909             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1910             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1911             assertion setting that is not met results in failure of the start job (which means this is logged
1912             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1913             C<failed> state (or in fact result in any state change of the unit), it affects
1914             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1915             requirements are not met, and when this is something the administrator or user should look
1916             into.",
1917             'type' => 'leaf',
1918             'value_type' => 'uniline'
1919             },
1920             'AssertUser',
1921             {
1922             'description' => "Similar to the C<ConditionArchitecture>,
1923             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1924             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1925             assertion setting that is not met results in failure of the start job (which means this is logged
1926             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1927             C<failed> state (or in fact result in any state change of the unit), it affects
1928             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1929             requirements are not met, and when this is something the administrator or user should look
1930             into.",
1931             'type' => 'leaf',
1932             'value_type' => 'uniline'
1933             },
1934             'AssertGroup',
1935             {
1936             'description' => "Similar to the C<ConditionArchitecture>,
1937             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1938             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1939             assertion setting that is not met results in failure of the start job (which means this is logged
1940             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1941             C<failed> state (or in fact result in any state change of the unit), it affects
1942             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1943             requirements are not met, and when this is something the administrator or user should look
1944             into.",
1945             'type' => 'leaf',
1946             'value_type' => 'uniline'
1947             },
1948             'AssertControlGroupController',
1949             {
1950             'description' => "Similar to the C<ConditionArchitecture>,
1951             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1952             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1953             assertion setting that is not met results in failure of the start job (which means this is logged
1954             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1955             C<failed> state (or in fact result in any state change of the unit), it affects
1956             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1957             requirements are not met, and when this is something the administrator or user should look
1958             into.",
1959             'type' => 'leaf',
1960             'value_type' => 'uniline'
1961             },
1962             'AssertMemory',
1963             {
1964             'description' => "Similar to the C<ConditionArchitecture>,
1965             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1966             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1967             assertion setting that is not met results in failure of the start job (which means this is logged
1968             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1969             C<failed> state (or in fact result in any state change of the unit), it affects
1970             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1971             requirements are not met, and when this is something the administrator or user should look
1972             into.",
1973             'type' => 'leaf',
1974             'value_type' => 'uniline'
1975             },
1976             'AssertCPUs',
1977             {
1978             'description' => "Similar to the C<ConditionArchitecture>,
1979             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1980             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1981             assertion setting that is not met results in failure of the start job (which means this is logged
1982             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1983             C<failed> state (or in fact result in any state change of the unit), it affects
1984             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1985             requirements are not met, and when this is something the administrator or user should look
1986             into.",
1987             'type' => 'leaf',
1988             'value_type' => 'uniline'
1989             },
1990             'AssertOSRelease',
1991             {
1992             'description' => "Similar to the C<ConditionArchitecture>,
1993             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
1994             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1995             assertion setting that is not met results in failure of the start job (which means this is logged
1996             loudly). Note that hitting a configured assertion does not cause the unit to enter the
1997             C<failed> state (or in fact result in any state change of the unit), it affects
1998             only the job queued for it. Use assertion expressions for units that cannot operate when specific
1999             requirements are not met, and when this is something the administrator or user should look
2000             into.",
2001             'type' => 'leaf',
2002             'value_type' => 'uniline'
2003             },
2004             'AssertMemoryPressure',
2005             {
2006             'description' => "Similar to the C<ConditionArchitecture>,
2007             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
2008             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
2009             assertion setting that is not met results in failure of the start job (which means this is logged
2010             loudly). Note that hitting a configured assertion does not cause the unit to enter the
2011             C<failed> state (or in fact result in any state change of the unit), it affects
2012             only the job queued for it. Use assertion expressions for units that cannot operate when specific
2013             requirements are not met, and when this is something the administrator or user should look
2014             into.",
2015             'type' => 'leaf',
2016             'value_type' => 'uniline'
2017             },
2018             'AssertCPUPressure',
2019             {
2020             'description' => "Similar to the C<ConditionArchitecture>,
2021             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
2022             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
2023             assertion setting that is not met results in failure of the start job (which means this is logged
2024             loudly). Note that hitting a configured assertion does not cause the unit to enter the
2025             C<failed> state (or in fact result in any state change of the unit), it affects
2026             only the job queued for it. Use assertion expressions for units that cannot operate when specific
2027             requirements are not met, and when this is something the administrator or user should look
2028             into.",
2029             'type' => 'leaf',
2030             'value_type' => 'uniline'
2031             },
2032             'AssertIOPressure',
2033             {
2034             'description' => "Similar to the C<ConditionArchitecture>,
2035             C<ConditionVirtualization>, \x{2026}, condition settings described above, these settings
2036             add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
2037             assertion setting that is not met results in failure of the start job (which means this is logged
2038             loudly). Note that hitting a configured assertion does not cause the unit to enter the
2039             C<failed> state (or in fact result in any state change of the unit), it affects
2040             only the job queued for it. Use assertion expressions for units that cannot operate when specific
2041             requirements are not met, and when this is something the administrator or user should look
2042             into.",
2043             'type' => 'leaf',
2044             'value_type' => 'uniline'
2045             },
2046             'StartLimitInterval',
2047             {
2048             'status' => 'deprecated',
2049             'type' => 'leaf',
2050             'value_type' => 'uniline',
2051             'warn' => 'StartLimitInterval is now StartLimitIntervalSec.'
2052             },
2053             'OnFailureIsolate',
2054             {
2055             'status' => 'deprecated',
2056             'type' => 'leaf',
2057             'value_type' => 'uniline',
2058             'warn' => 'OnFailureIsolate is now OnFailureJobMode.'
2059             }
2060             ],
2061             'generated_by' => 'parse-man.pl from systemd 250 doc',
2062             'license' => 'LGPLv2.1+',
2063             'name' => 'Systemd::Section::Unit'
2064             }
2065             ]
2066             ;
2067