1SYSTEMD.UNIT(5)                  systemd.unit                  SYSTEMD.UNIT(5)
2
3
4

NAME

6       systemd.unit - Unit configuration
7

SYNOPSIS

9       service.service, socket.socket, device.device, mount.mount,
10       automount.automount, swap.swap, target.target, path.path, timer.timer,
11       slice.slice, scope.scope
12
13   System Unit Search Path
14       /etc/systemd/system.control/*
15       /run/systemd/system.control/*
16       /run/systemd/transient/*
17       /run/systemd/generator.early/*
18       /etc/systemd/system/*
19       /etc/systemd/systemd.attached/*
20       /run/systemd/system/*
21       /run/systemd/systemd.attached/*
22       /run/systemd/generator/*
23       ...
24       /usr/lib/systemd/system/*
25       /run/systemd/generator.late/*
26
27   User Unit Search Path
28       ~/.config/systemd/user.control/*
29       $XDG_RUNTIME_DIR/systemd/user.control/*
30       $XDG_RUNTIME_DIR/systemd/transient/*
31       $XDG_RUNTIME_DIR/systemd/generator.early/*
32       $XDG_CONFIG_HOME/systemd/user/*
33       $XDG_CONFIG_DIRS/systemd/user/*
34       /etc/systemd/user/*
35       $XDG_RUNTIME_DIR/systemd/user/*
36       /run/systemd/user/*
37       $XDG_RUNTIME_DIR/systemd/generator/*
38       $XDG_DATA_HOME/systemd/user/*
39       $XDG_DATA_DIRS/systemd/user/*
40       ...
41       /usr/lib/systemd/user/*
42       $XDG_RUNTIME_DIR/systemd/generator.late/*
43

DESCRIPTION

45       A unit file is a plain text ini-style file that encodes information
46       about a service, a socket, a device, a mount point, an automount point,
47       a swap file or partition, a start-up target, a watched file system
48       path, a timer controlled and supervised by systemd(1), a resource
49       management slice or a group of externally created processes. See
50       systemd.syntax(7) for a general description of the syntax.
51
52       This man page lists the common configuration options of all the unit
53       types. These options need to be configured in the [Unit] or [Install]
54       sections of the unit files.
55
56       In addition to the generic [Unit] and [Install] sections described
57       here, each unit may have a type-specific section, e.g. [Service] for a
58       service unit. See the respective man pages for more information:
59       systemd.service(5), systemd.socket(5), systemd.device(5),
60       systemd.mount(5), systemd.automount(5), systemd.swap(5),
61       systemd.target(5), systemd.path(5), systemd.timer(5), systemd.slice(5),
62       systemd.scope(5).
63
64       Unit files are loaded from a set of paths determined during
65       compilation, described in the next section.
66
67       Valid unit names consist of a "name prefix" and a dot and a suffix
68       specifying the unit type. The "unit prefix" must consist of one or more
69       valid characters (ASCII letters, digits, ":", "-", "_", ".", and "\").
70       The total length of the unit name including the suffix must not exceed
71       256 characters. The type suffix must be one of ".service", ".socket",
72       ".device", ".mount", ".automount", ".swap", ".target", ".path",
73       ".timer", ".slice", or ".scope".
74
75       Units names can be parameterized by a single argument called the
76       "instance name". The unit is then constructed based on a "template
77       file" which serves as the definition of multiple services or other
78       units. A template unit must have a single "@" at the end of the name
79       (right before the type suffix). The name of the full unit is formed by
80       inserting the instance name between "@" and the unit type suffix. In
81       the unit file itself, the instance parameter may be referred to using
82       "%i" and other specifiers, see below.
83
84       Unit files may contain additional options on top of those listed here.
85       If systemd encounters an unknown option, it will write a warning log
86       message but continue loading the unit. If an option or section name is
87       prefixed with X-, it is ignored completely by systemd. Options within
88       an ignored section do not need the prefix. Applications may use this to
89       include additional information in the unit files.
90
91       Units can be aliased (have an alternative name), by creating a symlink
92       from the new name to the existing name in one of the unit search paths.
93       For example, systemd-networkd.service has the alias
94       dbus-org.freedesktop.network1.service, created during installation as a
95       symlink, so when systemd is asked through D-Bus to load
96       dbus-org.freedesktop.network1.service, it'll load
97       systemd-networkd.service. As another example, default.target — the
98       default system target started at boot — is commonly symlinked (aliased)
99       to either multi-user.target or graphical.target to select what is
100       started by default. Alias names may be used in commands like disable,
101       start, stop, status, and similar, and in all unit dependency
102       directives, including Wants=, Requires=, Before=, After=. Aliases
103       cannot be used with the preset command.
104
105       Aliases obey the following restrictions: a unit of a certain type
106       (".service", ".socket", ...) can only be aliased by a name with the
107       same type suffix. A plain unit (not a template or an instance), may
108       only be aliased by a plain name. A template instance may only be
109       aliased by another template instance, and the instance part must be
110       identical. A template may be aliased by another template (in which case
111       the alias applies to all instances of the template). As a special case,
112       a template instance (e.g.  "alias@inst.service") may be a symlink to
113       different template (e.g.  "template@inst.service"). In that case, just
114       this specific instance is aliased, while other instances of the
115       template (e.g.  "alias@foo.service", "alias@bar.service") are not
116       aliased. Those rule preserve the requirement that the instance (if any)
117       is always uniquely defined for a given unit and all its aliases.
118
119       Unit files may specify aliases through the Alias= directive in the
120       [Install] section. When the unit is enabled, symlinks will be created
121       for those names, and removed when the unit is disabled. For example,
122       reboot.target specifies Alias=ctrl-alt-del.target, so when enabled, the
123       symlink /etc/systemd/systemd/ctrl-alt-del.service pointing to the
124       reboot.target file will be created, and when Ctrl+Alt+Del is invoked,
125       systemd will look for the ctrl-alt-del.service and execute
126       reboot.service.  systemd does not look at the [Install] section at all
127       during normal operation, so any directives in that section only have an
128       effect through the symlinks created during enablement.
129
130       Along with a unit file foo.service, the directory foo.service.wants/
131       may exist. All unit files symlinked from such a directory are
132       implicitly added as dependencies of type Wants= to the unit. Similar
133       functionality exists for Requires= type dependencies as well, the
134       directory suffix is .requires/ in this case. This functionality is
135       useful to hook units into the start-up of other units, without having
136       to modify their unit files. For details about the semantics of Wants=,
137       see below. The preferred way to create symlinks in the .wants/ or
138       .requires/ directory of a unit file is by embedding the dependency in
139       [Install] section of the target unit, and creating the symlink in the
140       file system with the enable or preset commands of systemctl(1).
141
142       Along with a unit file foo.service, a "drop-in" directory
143       foo.service.d/ may exist. All files with the suffix ".conf" from this
144       directory will be parsed after the unit file itself is parsed. This is
145       useful to alter or add configuration settings for a unit, without
146       having to modify unit files. Drop-in files must contain appropriate
147       section headers. For instantiated units, this logic will first look for
148       the instance ".d/" subdirectory (e.g.  "foo@bar.service.d/") and read
149       its ".conf" files, followed by the template ".d/" subdirectory (e.g.
150       "foo@.service.d/") and the ".conf" files there. Moreover for units
151       names containing dashes ("-"), the set of directories generated by
152       truncating the unit name after all dashes is searched too.
153       Specifically, for a unit name foo-bar-baz.service not only the regular
154       drop-in directory foo-bar-baz.service.d/ is searched but also both
155       foo-bar-.service.d/ and foo-.service.d/. This is useful for defining
156       common drop-ins for a set of related units, whose names begin with a
157       common prefix. This scheme is particularly useful for mount, automount
158       and slice units, whose systematic naming structure is built around
159       dashes as component separators. Note that equally named drop-in files
160       further down the prefix hierarchy override those further up, i.e.
161       foo-bar-.service.d/10-override.conf overrides
162       foo-.service.d/10-override.conf.
163
164       In cases of unit aliases (described above), dropins for the aliased
165       name and all aliases are loaded. In the example of default.target
166       aliasing graphical.target, default.target.d/, default.target.wants/,
167       default.target.requires/, graphical.target.d/, graphical.target.wants/,
168       graphical.target.requires/ would all be read. For templates, dropins
169       for the template, any template aliases, the template instance, and all
170       alias instances are read. When just a specific template instance is
171       aliased, then the dropins for the target template, the target template
172       instance, and the alias template instance are read.
173
174       In addition to /etc/systemd/system, the drop-in ".d/" directories for
175       system services can be placed in /usr/lib/systemd/system or
176       /run/systemd/system directories. Drop-in files in /etc take precedence
177       over those in /run which in turn take precedence over those in
178       /usr/lib. Drop-in files under any of these directories take precedence
179       over unit files wherever located. Multiple drop-in files with different
180       names are applied in lexicographic order, regardless of which of the
181       directories they reside in.
182
183       Units also support a top-level drop-in with type.d/, where type may be
184       e.g.  "service" or "socket", that allows altering or adding to the
185       settings of all corresponding unit files on the system. The formatting
186       and precedence of applying drop-in configurations follow what is
187       defined above. Configurations in type.d/ have the lowest precedence
188       compared to settings in the name specific override directories. So the
189       contents of foo-.service.d/10-override.conf would override
190       service.d/10-override.conf.
191
192       Note that while systemd offers a flexible dependency system between
193       units it is recommended to use this functionality only sparingly and
194       instead rely on techniques such as bus-based or socket-based activation
195       which make dependencies implicit, resulting in a both simpler and more
196       flexible system.
197
198       As mentioned above, a unit may be instantiated from a template file.
199       This allows creation of multiple units from a single configuration
200       file. If systemd looks for a unit configuration file, it will first
201       search for the literal unit name in the file system. If that yields no
202       success and the unit name contains an "@" character, systemd will look
203       for a unit template that shares the same name but with the instance
204       string (i.e. the part between the "@" character and the suffix)
205       removed. Example: if a service getty@tty3.service is requested and no
206       file by that name is found, systemd will look for getty@.service and
207       instantiate a service from that configuration file if it is found.
208
209       To refer to the instance string from within the configuration file you
210       may use the special "%i" specifier in many of the configuration
211       options. See below for details.
212
213       If a unit file is empty (i.e. has the file size 0) or is symlinked to
214       /dev/null, its configuration will not be loaded and it appears with a
215       load state of "masked", and cannot be activated. Use this as an
216       effective way to fully disable a unit, making it impossible to start it
217       even manually.
218
219       The unit file format is covered by the Interface Portability and
220       Stability Promise[1].
221

STRING ESCAPING FOR INCLUSION IN UNIT NAMES

223       Sometimes it is useful to convert arbitrary strings into unit names. To
224       facilitate this, a method of string escaping is used, in order to map
225       strings containing arbitrary byte values (except NUL) into valid unit
226       names and their restricted character set. A common special case are
227       unit names that reflect paths to objects in the file system hierarchy.
228       Example: a device unit dev-sda.device refers to a device with the
229       device node /dev/sda in the file system.
230
231       The escaping algorithm operates as follows: given a string, any "/"
232       character is replaced by "-", and all other characters which are not
233       ASCII alphanumerics or "_" are replaced by C-style "\x2d" escapes. In
234       addition, "."  is replaced with such a C-style escape when it would
235       appear as the first character in the escaped string.
236
237       When the input qualifies as absolute file system path, this algorithm
238       is extended slightly: the path to the root directory "/" is encoded as
239       single dash "-". In addition, any leading, trailing or duplicate "/"
240       characters are removed from the string before transformation. Example:
241       /foo//bar/baz/ becomes "foo-bar-baz".
242
243       This escaping is fully reversible, as long as it is known whether the
244       escaped string was a path (the unescaping results are different for
245       paths and non-path strings). The systemd-escape(1) command may be used
246       to apply and reverse escaping on arbitrary strings. Use systemd-escape
247       --path to escape path strings, and systemd-escape without --path
248       otherwise.
249

AUTOMATIC DEPENDENCIES

251   Implicit Dependencies
252       A number of unit dependencies are implicitly established, depending on
253       unit type and unit configuration. These implicit dependencies can make
254       unit configuration file cleaner. For the implicit dependencies in each
255       unit type, please refer to section "Implicit Dependencies" in
256       respective man pages.
257
258       For example, service units with Type=dbus automatically acquire
259       dependencies of type Requires= and After= on dbus.socket. See
260       systemd.service(5) for details.
261
262   Default Dependencies
263       Default dependencies are similar to implicit dependencies, but can be
264       turned on and off by setting DefaultDependencies= to yes (the default)
265       and no, while implicit dependencies are always in effect. See section
266       "Default Dependencies" in respective man pages for the effect of
267       enabling DefaultDependencies= in each unit types.
268
269       For example, target units will complement all configured dependencies
270       of type Wants= or Requires= with dependencies of type After= unless
271       DefaultDependencies=no is set in the specified units. See
272       systemd.target(5) for details. Note that this behavior can be turned
273       off by setting DefaultDependencies=no.
274

UNIT FILE LOAD PATH

276       Unit files are loaded from a set of paths determined during
277       compilation, described in the two tables below. Unit files found in
278       directories listed earlier override files with the same name in
279       directories lower in the list.
280
281       When the variable $SYSTEMD_UNIT_PATH is set, the contents of this
282       variable overrides the unit load path. If $SYSTEMD_UNIT_PATH ends with
283       an empty component (":"), the usual unit load path will be appended to
284       the contents of the variable.
285
286       Table 1.  Load path when running in system mode (--system).
287       ┌──────────────────────────────┬────────────────────────────┐
288Path                          Description                
289       ├──────────────────────────────┼────────────────────────────┤
290       │/etc/systemd/system.control   │ Persistent and transient   │
291       ├──────────────────────────────┤ configuration created      │
292       │/run/systemd/system.control   │ using the dbus API         │
293       ├──────────────────────────────┼────────────────────────────┤
294       │/run/systemd/transient        │ Dynamic configuration for  │
295       │                              │ transient units            │
296       ├──────────────────────────────┼────────────────────────────┤
297       │/run/systemd/generator.early  │ Generated units with high  │
298       │                              │ priority (see early-dir in │
299       │                              │ systemd.generator(7))      │
300       ├──────────────────────────────┼────────────────────────────┤
301       │/etc/systemd/system           │ System units created by    │
302       │                              │ the administrator          │
303       ├──────────────────────────────┼────────────────────────────┤
304       │/run/systemd/system           │ Runtime units              │
305       ├──────────────────────────────┼────────────────────────────┤
306       │/run/systemd/generator        │ Generated units with       │
307       │                              │ medium priority (see       │
308       │                              │ normal-dir in              │
309       │                              │ systemd.generator(7))      │
310       ├──────────────────────────────┼────────────────────────────┤
311       │/usr/local/lib/systemd/system │ System units installed by  │
312       │                              │ the administrator          │
313       ├──────────────────────────────┼────────────────────────────┤
314       │/usr/lib/systemd/system       │ System units installed by  │
315       │                              │ the distribution package   │
316       │                              │ manager                    │
317       ├──────────────────────────────┼────────────────────────────┤
318       │/run/systemd/generator.late   │ Generated units with low   │
319       │                              │ priority (see late-dir in  │
320       │                              │ systemd.generator(7))      │
321       └──────────────────────────────┴────────────────────────────┘
322
323       Table 2.  Load path when running in user mode (--user).
324       ┌────────────────────────────────────────┬────────────────────────────┐
325Path                                    Description                
326       ├────────────────────────────────────────┼────────────────────────────┤
327       │$XDG_CONFIG_HOME/systemd/user.control   │ Persistent and transient   │
328       │or                                      │ configuration created      │
329       │~/.config/systemd/user.control          │ using the dbus API         │
330       ├────────────────────────────────────────┤ ($XDG_CONFIG_HOME is used  │
331       │$XDG_RUNTIME_DIR/systemd/user.control   │ if set, ~/.config          │
332       │                                        │ otherwise)                 │
333       ├────────────────────────────────────────┼────────────────────────────┤
334       │/run/systemd/transient                  │ Dynamic configuration for  │
335       │                                        │ transient units            │
336       ├────────────────────────────────────────┼────────────────────────────┤
337       │/run/systemd/generator.early            │ Generated units with high  │
338       │                                        │ priority (see early-dir in │
339       │                                        │ systemd.generator(7))      │
340       ├────────────────────────────────────────┼────────────────────────────┤
341       │$XDG_CONFIG_HOME/systemd/user or        │ User configuration         │
342       │$HOME/.config/systemd/user              │ ($XDG_CONFIG_HOME is used  │
343       │                                        │ if set, ~/.config          │
344       │                                        │ otherwise)                 │
345       ├────────────────────────────────────────┼────────────────────────────┤
346       │$XDG_CONFIG_DIRS/systemd/user or        │ Additional configuration   │
347       │/etc/xdg/systemd/user                   │ directories as specified   │
348       │                                        │ by the XDG base directory  │
349       │                                        │ specification              │
350       │                                        │ ($XDG_CONFIG_DIRS is used  │
351       │                                        │ if set, /etc/xdg           │
352       │                                        │ otherwise)                 │
353       ├────────────────────────────────────────┼────────────────────────────┤
354       │/etc/systemd/user                       │ User units created by the  │
355       │                                        │ administrator              │
356       ├────────────────────────────────────────┼────────────────────────────┤
357       │$XDG_RUNTIME_DIR/systemd/user           │ Runtime units (only used   │
358       │                                        │ when $XDG_RUNTIME_DIR is   │
359       │                                        │ set)                       │
360       ├────────────────────────────────────────┼────────────────────────────┤
361       │/run/systemd/user                       │ Runtime units              │
362       ├────────────────────────────────────────┼────────────────────────────┤
363       │$XDG_RUNTIME_DIR/systemd/generator      │ Generated units with       │
364       │                                        │ medium priority (see       │
365       │                                        │ normal-dir in              │
366       │                                        │ systemd.generator(7))      │
367       ├────────────────────────────────────────┼────────────────────────────┤
368       │$XDG_DATA_HOME/systemd/user or          │ Units of packages that     │
369       │$HOME/.local/share/systemd/user         │ have been installed in the │
370       │                                        │ home directory             │
371       │                                        │ ($XDG_DATA_HOME is used if │
372       │                                        │ set, ~/.local/share        │
373       │                                        │ otherwise)                 │
374       ├────────────────────────────────────────┼────────────────────────────┤
375       │$XDG_DATA_DIRS/systemd/user or          │ Additional data            │
376       │/usr/local/share/systemd/user and       │ directories as specified   │
377       │/usr/share/systemd/user                 │ by the XDG base directory  │
378       │                                        │ specification              │
379       │                                        │ ($XDG_DATA_DIRS is used if │
380       │                                        │ set, /usr/local/share and  │
381       │                                        │ /usr/share otherwise)      │
382       ├────────────────────────────────────────┼────────────────────────────┤
383       │$dir/systemd/user for each $dir in      │ Additional locations for   │
384$XDG_DATA_DIRS                          │ installed user units, one  │
385       │                                        │ for each entry in          │
386       │                                        │ $XDG_DATA_DIRS
387       ├────────────────────────────────────────┼────────────────────────────┤
388       │/usr/local/lib/systemd/user             │ User units installed by    │
389       │                                        │ the administrator          │
390       ├────────────────────────────────────────┼────────────────────────────┤
391       │/usr/lib/systemd/user                   │ User units installed by    │
392       │                                        │ the distribution package   │
393       │                                        │ manager                    │
394       ├────────────────────────────────────────┼────────────────────────────┤
395       │$XDG_RUNTIME_DIR/systemd/generator.late │ Generated units with low   │
396       │                                        │ priority (see late-dir in  │
397       │                                        │ systemd.generator(7))      │
398       └────────────────────────────────────────┴────────────────────────────┘
399
400       The set of load paths for the user manager instance may be augmented or
401       changed using various environment variables. And environment variables
402       may in turn be set using environment generators, see
403       systemd.environment-generator(7). In particular, $XDG_DATA_HOME and
404       $XDG_DATA_DIRS may be easily set using systemd-environment-d-
405       generator(8). Thus, directories listed here are just the defaults. To
406       see the actual list that would be used based on compilation options and
407       current environment use
408
409           systemd-analyze --user unit-paths
410
411       Moreover, additional units might be loaded into systemd from
412       directories not on the unit load path by creating a symlink pointing to
413       a unit file in the directories. You can use systemctl link for this
414       operation. See systemctl(1) for its usage and precaution.
415

UNIT GARBAGE COLLECTION

417       The system and service manager loads a unit's configuration
418       automatically when a unit is referenced for the first time. It will
419       automatically unload the unit configuration and state again when the
420       unit is not needed anymore ("garbage collection"). A unit may be
421       referenced through a number of different mechanisms:
422
423        1. Another loaded unit references it with a dependency such as After=,
424           Wants=, ...
425
426        2. The unit is currently starting, running, reloading or stopping.
427
428        3. The unit is currently in the failed state. (But see below.)
429
430        4. A job for the unit is pending.
431
432        5. The unit is pinned by an active IPC client program.
433
434        6. The unit is a special "perpetual" unit that is always active and
435           loaded. Examples for perpetual units are the root mount unit
436           -.mount or the scope unit init.scope that the service manager
437           itself lives in.
438
439        7. The unit has running processes associated with it.
440
441       The garbage collection logic may be altered with the CollectMode=
442       option, which allows configuration whether automatic unloading of units
443       that are in failed state is permissible, see below.
444
445       Note that when a unit's configuration and state is unloaded, all
446       execution results, such as exit codes, exit signals, resource
447       consumption and other statistics are lost, except for what is stored in
448       the log subsystem.
449
450       Use systemctl daemon-reload or an equivalent command to reload unit
451       configuration while the unit is already loaded. In this case all
452       configuration settings are flushed out and replaced with the new
453       configuration (which however might not be in effect immediately),
454       however all runtime state is saved/restored.
455

[UNIT] SECTION OPTIONS

457       The unit file may include a [Unit] section, which carries generic
458       information about the unit that is not dependent on the type of unit:
459
460       Description=
461           A human readable name for the unit. This is used by systemd (and
462           other UIs) as the label for the unit, so this string should
463           identify the unit rather than describe it, despite the name.
464           "Apache2 Web Server" is a good example. Bad examples are
465           "high-performance light-weight HTTP server" (too generic) or
466           "Apache2" (too specific and meaningless for people who do not know
467           Apache).  systemd will use this string as a noun in status messages
468           ("Starting description...", "Started description.", "Reached target
469           description.", "Failed to start description."), so it should be
470           capitalized, and should not be a full sentence or a phrase with a
471           continuous verb. Bad examples include "exiting the container" or
472           "updating the database once per day.".
473
474       Documentation=
475           A space-separated list of URIs referencing documentation for this
476           unit or its configuration. Accepted are only URIs of the types
477           "http://", "https://", "file:", "info:", "man:". For more
478           information about the syntax of these URIs, see uri(7). The URIs
479           should be listed in order of relevance, starting with the most
480           relevant. It is a good idea to first reference documentation that
481           explains what the unit's purpose is, followed by how it is
482           configured, followed by any other related documentation. This
483           option may be specified more than once, in which case the specified
484           list of URIs is merged. If the empty string is assigned to this
485           option, the list is reset and all prior assignments will have no
486           effect.
487
488       Wants=
489           Configures requirement dependencies on other units. This option may
490           be specified more than once or multiple space-separated units may
491           be specified in one option in which case dependencies for all
492           listed names will be created. Dependencies of this type may also be
493           configured outside of the unit configuration file by adding a
494           symlink to a .wants/ directory accompanying the unit file. For
495           details, see above.
496
497           Units listed in this option will be started if the configuring unit
498           is. However, if the listed units fail to start or cannot be added
499           to the transaction, this has no impact on the validity of the
500           transaction as a whole, and this unit will still be started. This
501           is the recommended way to hook the start-up of one unit to the
502           start-up of another unit.
503
504           Note that requirement dependencies do not influence the order in
505           which services are started or stopped. This has to be configured
506           independently with the After= or Before= options. If unit
507           foo.service pulls in unit bar.service as configured with Wants= and
508           no ordering is configured with After= or Before=, then both units
509           will be started simultaneously and without any delay between them
510           if foo.service is activated.
511
512       Requires=
513           Similar to Wants=, but declares a stronger dependency. Dependencies
514           of this type may also be configured by adding a symlink to a
515           .requires/ directory accompanying the unit file.
516
517           If this unit gets activated, the units listed will be activated as
518           well. If one of the other units fails to activate, and an ordering
519           dependency After= on the failing unit is set, this unit will not be
520           started. Besides, with or without specifying After=, this unit will
521           be stopped if one of the other units is explicitly stopped.
522
523           Often, it is a better choice to use Wants= instead of Requires= in
524           order to achieve a system that is more robust when dealing with
525           failing services.
526
527           Note that this dependency type does not imply that the other unit
528           always has to be in active state when this unit is running.
529           Specifically: failing condition checks (such as
530           ConditionPathExists=, ConditionPathIsSymbolicLink=, ... — see
531           below) do not cause the start job of a unit with a Requires=
532           dependency on it to fail. Also, some unit types may deactivate on
533           their own (for example, a service process may decide to exit
534           cleanly, or a device may be unplugged by the user), which is not
535           propagated to units having a Requires= dependency. Use the BindsTo=
536           dependency type together with After= to ensure that a unit may
537           never be in active state without a specific other unit also in
538           active state (see below).
539
540       Requisite=
541           Similar to Requires=. However, if the units listed here are not
542           started already, they will not be started and the starting of this
543           unit will fail immediately.  Requisite= does not imply an ordering
544           dependency, even if both units are started in the same transaction.
545           Hence this setting should usually be combined with After=, to
546           ensure this unit is not started before the other unit.
547
548           When Requisite=b.service is used on a.service, this dependency will
549           show as RequisiteOf=a.service in property listing of b.service.
550           RequisiteOf= dependency cannot be specified directly.
551
552       BindsTo=
553           Configures requirement dependencies, very similar in style to
554           Requires=. However, this dependency type is stronger: in addition
555           to the effect of Requires= it declares that if the unit bound to is
556           stopped, this unit will be stopped too. This means a unit bound to
557           another unit that suddenly enters inactive state will be stopped
558           too. Units can suddenly, unexpectedly enter inactive state for
559           different reasons: the main process of a service unit might
560           terminate on its own choice, the backing device of a device unit
561           might be unplugged or the mount point of a mount unit might be
562           unmounted without involvement of the system and service manager.
563
564           When used in conjunction with After= on the same unit the behaviour
565           of BindsTo= is even stronger. In this case, the unit bound to
566           strictly has to be in active state for this unit to also be in
567           active state. This not only means a unit bound to another unit that
568           suddenly enters inactive state, but also one that is bound to
569           another unit that gets skipped due to a failed condition check
570           (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, ... —
571           see below) will be stopped, should it be running. Hence, in many
572           cases it is best to combine BindsTo= with After=.
573
574           When BindsTo=b.service is used on a.service, this dependency will
575           show as BoundBy=a.service in property listing of b.service.
576           BoundBy= dependency cannot be specified directly.
577
578       PartOf=
579           Configures dependencies similar to Requires=, but limited to
580           stopping and restarting of units. When systemd stops or restarts
581           the units listed here, the action is propagated to this unit. Note
582           that this is a one-way dependency — changes to this unit do not
583           affect the listed units.
584
585           When PartOf=b.service is used on a.service, this dependency will
586           show as ConsistsOf=a.service in property listing of b.service.
587           ConsistsOf= dependency cannot be specified directly.
588
589       Conflicts=
590           A space-separated list of unit names. Configures negative
591           requirement dependencies. If a unit has a Conflicts= setting on
592           another unit, starting the former will stop the latter and vice
593           versa.
594
595           Note that this setting does not imply an ordering dependency,
596           similarly to the Wants= and Requires= dependencies described above.
597           This means that to ensure that the conflicting unit is stopped
598           before the other unit is started, an After= or Before= dependency
599           must be declared. It doesn't matter which of the two ordering
600           dependencies is used, because stop jobs are always ordered before
601           start jobs, see the discussion in Before=/After= below.
602
603           If unit A that conflicts with unit B is scheduled to be started at
604           the same time as B, the transaction will either fail (in case both
605           are required parts of the transaction) or be modified to be fixed
606           (in case one or both jobs are not a required part of the
607           transaction). In the latter case, the job that is not required will
608           be removed, or in case both are not required, the unit that
609           conflicts will be started and the unit that is conflicted is
610           stopped.
611
612       Before=, After=
613           These two settings expect a space-separated list of unit names.
614           They may be specified more than once, in which case dependencies
615           for all listed names are created.
616
617           Those two settings configure ordering dependencies between units.
618           If unit foo.service contains the setting Before=bar.service and
619           both units are being started, bar.service's start-up is delayed
620           until foo.service has finished starting up.  After= is the inverse
621           of Before=, i.e. while Before= ensures that the configured unit is
622           started before the listed unit begins starting up, After= ensures
623           the opposite, that the listed unit is fully started up before the
624           configured unit is started.
625
626           When two units with an ordering dependency between them are shut
627           down, the inverse of the start-up order is applied. I.e. if a unit
628           is configured with After= on another unit, the former is stopped
629           before the latter if both are shut down. Given two units with any
630           ordering dependency between them, if one unit is shut down and the
631           other is started up, the shutdown is ordered before the start-up.
632           It doesn't matter if the ordering dependency is After= or Before=,
633           in this case. It also doesn't matter which of the two is shut down,
634           as long as one is shut down and the other is started up; the
635           shutdown is ordered before the start-up in all cases. If two units
636           have no ordering dependencies between them, they are shut down or
637           started up simultaneously, and no ordering takes place. It depends
638           on the unit type when precisely a unit has finished starting up.
639           Most importantly, for service units start-up is considered
640           completed for the purpose of Before=/After= when all its configured
641           start-up commands have been invoked and they either failed or
642           reported start-up success. Note that this does includes
643           ExecStartPost= (or ExecStopPost= for the shutdown case).
644
645           Note that those settings are independent of and orthogonal to the
646           requirement dependencies as configured by Requires=, Wants=,
647           Requisite=, or BindsTo=. It is a common pattern to include a unit
648           name in both the After= and Wants= options, in which case the unit
649           listed will be started before the unit that is configured with
650           these options.
651
652           Note that Before= dependencies on device units have no effect and
653           are not supported. Devices generally become available as a result
654           of an external hotplug event, and systemd creates the corresponding
655           device unit without delay.
656
657       OnFailure=
658           A space-separated list of one or more units that are activated when
659           this unit enters the "failed" state. A service unit using Restart=
660           enters the failed state only after the start limits are reached.
661
662       PropagatesReloadTo=, ReloadPropagatedFrom=
663           A space-separated list of one or more units where reload requests
664           on this unit will be propagated to, or reload requests on the other
665           unit will be propagated to this unit, respectively. Issuing a
666           reload request on a unit will automatically also enqueue a reload
667           request on all units that the reload request shall be propagated to
668           via these two settings.
669
670       JoinsNamespaceOf=
671           For units that start processes (such as service units), lists one
672           or more other units whose network and/or temporary file namespace
673           to join. This only applies to unit types which support the
674           PrivateNetwork=, NetworkNamespacePath= and PrivateTmp= directives
675           (see systemd.exec(5) for details). If a unit that has this setting
676           set is started, its processes will see the same /tmp, /var/tmp and
677           network namespace as one listed unit that is started. If multiple
678           listed units are already started, it is not defined which namespace
679           is joined. Note that this setting only has an effect if
680           PrivateNetwork=/NetworkNamespacePath= and/or PrivateTmp= is enabled
681           for both the unit that joins the namespace and the unit whose
682           namespace is joined.
683
684       RequiresMountsFor=
685           Takes a space-separated list of absolute paths. Automatically adds
686           dependencies of type Requires= and After= for all mount units
687           required to access the specified path.
688
689           Mount points marked with noauto are not mounted automatically
690           through local-fs.target, but are still honored for the purposes of
691           this option, i.e. they will be pulled in by this unit.
692
693       OnFailureJobMode=
694           Takes a value of "fail", "replace", "replace-irreversibly",
695           "isolate", "flush", "ignore-dependencies" or "ignore-requirements".
696           Defaults to "replace". Specifies how the units listed in OnFailure=
697           will be enqueued. See systemctl(1)'s --job-mode= option for details
698           on the possible values. If this is set to "isolate", only a single
699           unit may be listed in OnFailure=.
700
701       IgnoreOnIsolate=
702           Takes a boolean argument. If true, this unit will not be stopped
703           when isolating another unit. Defaults to false for service, target,
704           socket, timer, and path units, and true for slice, scope, device,
705           swap, mount, and automount units.
706
707       StopWhenUnneeded=
708           Takes a boolean argument. If true, this unit will be stopped when
709           it is no longer used. Note that, in order to minimize the work to
710           be executed, systemd will not stop units by default unless they are
711           conflicting with other units, or the user explicitly requested
712           their shut down. If this option is set, a unit will be
713           automatically cleaned up if no other active unit requires it.
714           Defaults to false.
715
716       RefuseManualStart=, RefuseManualStop=
717           Takes a boolean argument. If true, this unit can only be activated
718           or deactivated indirectly. In this case, explicit start-up or
719           termination requested by the user is denied, however if it is
720           started or stopped as a dependency of another unit, start-up or
721           termination will succeed. This is mostly a safety feature to ensure
722           that the user does not accidentally activate units that are not
723           intended to be activated explicitly, and not accidentally
724           deactivate units that are not intended to be deactivated. These
725           options default to false.
726
727       AllowIsolate=
728           Takes a boolean argument. If true, this unit may be used with the
729           systemctl isolate command. Otherwise, this will be refused. It
730           probably is a good idea to leave this disabled except for target
731           units that shall be used similar to runlevels in SysV init systems,
732           just as a precaution to avoid unusable system states. This option
733           defaults to false.
734
735       DefaultDependencies=
736           Takes a boolean argument. If yes, (the default), a few default
737           dependencies will implicitly be created for the unit. The actual
738           dependencies created depend on the unit type. For example, for
739           service units, these dependencies ensure that the service is
740           started only after basic system initialization is completed and is
741           properly terminated on system shutdown. See the respective man
742           pages for details. Generally, only services involved with early
743           boot or late shutdown should set this option to no. It is highly
744           recommended to leave this option enabled for the majority of common
745           units. If set to no, this option does not disable all implicit
746           dependencies, just non-essential ones.
747
748       CollectMode=
749           Tweaks the "garbage collection" algorithm for this unit. Takes one
750           of inactive or inactive-or-failed. If set to inactive the unit will
751           be unloaded if it is in the inactive state and is not referenced by
752           clients, jobs or other units — however it is not unloaded if it is
753           in the failed state. In failed mode, failed units are not unloaded
754           until the user invoked systemctl reset-failed on them to reset the
755           failed state, or an equivalent command. This behaviour is altered
756           if this option is set to inactive-or-failed: in this case the unit
757           is unloaded even if the unit is in a failed state, and thus an
758           explicitly resetting of the failed state is not necessary. Note
759           that if this mode is used unit results (such as exit codes, exit
760           signals, consumed resources, ...) are flushed out immediately after
761           the unit completed, except for what is stored in the logging
762           subsystem. Defaults to inactive.
763
764       FailureAction=, SuccessAction=
765           Configure the action to take when the unit stops and enters a
766           failed state or inactive state. Takes one of none, reboot,
767           reboot-force, reboot-immediate, poweroff, poweroff-force,
768           poweroff-immediate, exit, and exit-force. In system mode, all
769           options are allowed. In user mode, only none, exit, and exit-force
770           are allowed. Both options default to none.
771
772           If none is set, no action will be triggered.  reboot causes a
773           reboot following the normal shutdown procedure (i.e. equivalent to
774           systemctl reboot).  reboot-force causes a forced reboot which will
775           terminate all processes forcibly but should cause no dirty file
776           systems on reboot (i.e. equivalent to systemctl reboot -f) and
777           reboot-immediate causes immediate execution of the reboot(2) system
778           call, which might result in data loss (i.e. equivalent to systemctl
779           reboot -ff). Similarly, poweroff, poweroff-force,
780           poweroff-immediate have the effect of powering down the system with
781           similar semantics.  exit causes the manager to exit following the
782           normal shutdown procedure, and exit-force causes it terminate
783           without shutting down services. When exit or exit-force is used by
784           default the exit status of the main process of the unit (if this
785           applies) is returned from the service manager. However, this may be
786           overridden with FailureActionExitStatus=/SuccessActionExitStatus=,
787           see below.
788
789       FailureActionExitStatus=, SuccessActionExitStatus=
790           Controls the exit status to propagate back to an invoking container
791           manager (in case of a system service) or service manager (in case
792           of a user manager) when the FailureAction=/SuccessAction= are set
793           to exit or exit-force and the action is triggered. By default the
794           exit status of the main process of the triggering unit (if this
795           applies) is propagated. Takes a value in the range 0...255 or the
796           empty string to request default behaviour.
797
798       JobTimeoutSec=, JobRunningTimeoutSec=
799           When a job for this unit is queued, a timeout JobTimeoutSec= may be
800           configured. Similarly, JobRunningTimeoutSec= starts counting when
801           the queued job is actually started. If either time limit is
802           reached, the job will be cancelled, the unit however will not
803           change state or even enter the "failed" mode. This value defaults
804           to "infinity" (job timeouts disabled), except for device units
805           (JobRunningTimeoutSec= defaults to DefaultTimeoutStartSec=). NB:
806           this timeout is independent from any unit-specific timeout (for
807           example, the timeout set with TimeoutStartSec= in service units) as
808           the job timeout has no effect on the unit itself, only on the job
809           that might be pending for it. Or in other words: unit-specific
810           timeouts are useful to abort unit state changes, and revert them.
811           The job timeout set with this option however is useful to abort
812           only the job waiting for the unit state to change.
813
814       JobTimeoutAction=, JobTimeoutRebootArgument=
815           JobTimeoutAction= optionally configures an additional action to
816           take when the timeout is hit, see description of JobTimeoutSec= and
817           JobRunningTimeoutSec= above. It takes the same values as
818           StartLimitAction=. Defaults to none.  JobTimeoutRebootArgument=
819           configures an optional reboot string to pass to the reboot(2)
820           system call.
821
822       StartLimitIntervalSec=interval, StartLimitBurst=burst
823           Configure unit start rate limiting. Units which are started more
824           than burst times within an interval time interval are not permitted
825           to start any more. Use StartLimitIntervalSec= to configure the
826           checking interval (defaults to DefaultStartLimitIntervalSec= in
827           manager configuration file, set it to 0 to disable any kind of rate
828           limiting). Use StartLimitBurst= to configure how many starts per
829           interval are allowed (defaults to DefaultStartLimitBurst= in
830           manager configuration file). These configuration options are
831           particularly useful in conjunction with the service setting
832           Restart= (see systemd.service(5)); however, they apply to all kinds
833           of starts (including manual), not just those triggered by the
834           Restart= logic. Note that units which are configured for Restart=
835           and which reach the start limit are not attempted to be restarted
836           anymore; however, they may still be restarted manually at a later
837           point, after the interval has passed. From this point on, the
838           restart logic is activated again. Note that systemctl reset-failed
839           will cause the restart rate counter for a service to be flushed,
840           which is useful if the administrator wants to manually start a unit
841           and the start limit interferes with that. Note that this
842           rate-limiting is enforced after any unit condition checks are
843           executed, and hence unit activations with failing conditions do not
844           count towards this rate limit. This setting does not apply to
845           slice, target, device, and scope units, since they are unit types
846           whose activation may either never fail, or may succeed only a
847           single time.
848
849           When a unit is unloaded due to the garbage collection logic (see
850           above) its rate limit counters are flushed out too. This means that
851           configuring start rate limiting for a unit that is not referenced
852           continuously has no effect.
853
854       StartLimitAction=
855           Configure an additional action to take if the rate limit configured
856           with StartLimitIntervalSec= and StartLimitBurst= is hit. Takes the
857           same values as the FailureAction=/SuccessAction= settings. If none
858           is set, hitting the rate limit will trigger no action except that
859           the start will not be permitted. Defaults to none.
860
861       RebootArgument=
862           Configure the optional argument for the reboot(2) system call if
863           StartLimitAction= or FailureAction= is a reboot action. This works
864           just like the optional argument to systemctl reboot command.
865
866       SourcePath=
867           A path to a configuration file this unit has been generated from.
868           This is primarily useful for implementation of generator tools that
869           convert configuration from an external configuration file format
870           into native unit files. This functionality should not be used in
871           normal units.
872
873   Conditions and Asserts
874       Unit files may also include a number of Condition...= and Assert...=
875       settings. Before the unit is started, systemd will verify that the
876       specified conditions are true. If not, the starting of the unit will be
877       (mostly silently) skipped. Failing conditions will not result in the
878       unit being moved into the "failed" state. The conditions are checked at
879       the time the queued start job is to be executed. The ordering
880       dependencies are still respected, so other units are still pulled in
881       and ordered as if this unit was successfully activated. Use condition
882       expressions in order to skip units that do not apply to the local
883       system, for example because the kernel or runtime environment doesn't
884       require their functionality.
885
886       If multiple conditions are specified, the unit will be executed if all
887       of them apply (i.e. a logical AND is applied). Condition checks can use
888       a pipe symbol ("|") after the equals sign ("Condition...=|..."), which
889       causes the condition becomes a triggering condition. If at least one
890       triggering condition is defined for a unit, then the unit will be
891       executed if at least one of the triggering conditions apply and all of
892       the non-triggering conditions. If you prefix an argument with the pipe
893       symbol and an exclamation mark, the pipe symbol must be passed first,
894       the exclamation second. If any of these options is assigned the empty
895       string, the list of conditions is reset completely, all previous
896       condition settings (of any kind) will have no effect.
897
898       The AssertArchitecture=, AssertVirtualization=, ... options provide a
899       similar mechanism that causes the job to fail (instead of being
900       skipped). The failed check is logged. Units with failed conditions are
901       considered to be in a clean state and will be garbage collected if they
902       are not referenced. This means that when queried, the condition failure
903       may or may not show up in the state of the unit.
904
905       Note that neither assertion nor condition expressions result in unit
906       state changes. Also note that both are checked at the time the job is
907       to be executed, i.e. long after depending jobs and it itself were
908       queued. Thus, neither condition nor assertion expressions are suitable
909       for conditionalizing unit dependencies.
910
911       The condition verb of systemd-analyze(1) can be used to test condition
912       and assert expressions.
913
914       Except for ConditionPathIsSymbolicLink=, all path checks follow
915       symlinks.
916
917       ConditionArchitecture=
918           Check whether the system is running on a specific architecture.
919           Takes one of "x86", "x86-64", "ppc", "ppc-le", "ppc64", "ppc64-le",
920           "ia64", "parisc", "parisc64", "s390", "s390x", "sparc", "sparc64",
921           "mips", "mips-le", "mips64", "mips64-le", "alpha", "arm", "arm-be",
922           "arm64", "arm64-be", "sh", "sh64", "m68k", "tilegx", "cris", "arc",
923           "arc-be", or "native".
924
925           The architecture is determined from the information returned by
926           uname(2) and is thus subject to personality(2). Note that a
927           Personality= setting in the same unit file has no effect on this
928           condition. A special architecture name "native" is mapped to the
929           architecture the system manager itself is compiled for. The test
930           may be negated by prepending an exclamation mark.
931
932       ConditionVirtualization=
933           Check whether the system is executed in a virtualized environment
934           and optionally test whether it is a specific implementation. Takes
935           either boolean value to check if being executed in any virtualized
936           environment, or one of "vm" and "container" to test against a
937           generic type of virtualization solution, or one of "qemu", "kvm",
938           "zvm", "vmware", "microsoft", "oracle", "powervm", "xen", "bochs",
939           "uml", "bhyve", "qnx", "openvz", "lxc", "lxc-libvirt",
940           "systemd-nspawn", "docker", "podman", "rkt", "wsl", "proot", "acrn"
941           to test against a specific implementation, or "private-users" to
942           check whether we are running in a user namespace. See systemd-
943           detect-virt(1) for a full list of known virtualization technologies
944           and their identifiers. If multiple virtualization technologies are
945           nested, only the innermost is considered. The test may be negated
946           by prepending an exclamation mark.
947
948       ConditionHost=
949           ConditionHost= may be used to match against the hostname or machine
950           ID of the host. This either takes a hostname string (optionally
951           with shell style globs) which is tested against the locally set
952           hostname as returned by gethostname(2), or a machine ID formatted
953           as string (see machine-id(5)). The test may be negated by
954           prepending an exclamation mark.
955
956       ConditionKernelCommandLine=
957           ConditionKernelCommandLine= may be used to check whether a specific
958           kernel command line option is set (or if prefixed with the
959           exclamation mark — unset). The argument must either be a single
960           word, or an assignment (i.e. two words, separated by "="). In the
961           former case the kernel command line is searched for the word
962           appearing as is, or as left hand side of an assignment. In the
963           latter case, the exact assignment is looked for with right and left
964           hand side matching. This operates on the kernel command line
965           communicated to userspace via /proc/cmdline, except when the
966           service manager is invoked as payload of a container manager, in
967           which case the command line of PID 1 is used instead (i.e.
968           /proc/1/cmdline).
969
970       ConditionKernelVersion=
971           ConditionKernelVersion= may be used to check whether the kernel
972           version (as reported by uname -r) matches a certain expression (or
973           if prefixed with the exclamation mark does not match it). The
974           argument must be a list of (potentially quoted) expressions. For
975           each of the expressions, if it starts with one of "<", "<=", "=",
976           "!=", ">=", ">" a relative version comparison is done, otherwise
977           the specified string is matched with shell-style globs.
978
979           Note that using the kernel version string is an unreliable way to
980           determine which features are supported by a kernel, because of the
981           widespread practice of backporting drivers, features, and fixes
982           from newer upstream kernels into older versions provided by
983           distributions. Hence, this check is inherently unportable and
984           should not be used for units which may be used on different
985           distributions.
986
987       ConditionEnvironment=
988           ConditionEnvironment= may be used to check whether a specific
989           environment variable is set (or if prefixed with the exclamation
990           mark — unset) in the service manager's environment block. The
991           argument may be a single word, to check if the variable with this
992           name is defined in the environment block, or an assignment
993           ("name=value"), to check if the variable with this exact value is
994           defined. Note that the environment block of the service manager
995           itself is checked, i.e. not any variables defined with Environment=
996           or EnvironmentFile=, as described above. This is particularly
997           useful when the service manager runs inside a containerized
998           environment or as per-user service manager, in order to check for
999           variables passed in by the enclosing container manager or PAM.
1000
1001       ConditionSecurity=
1002           ConditionSecurity= may be used to check whether the given security
1003           technology is enabled on the system. Currently, the recognized
1004           values are "selinux", "apparmor", "tomoyo", "ima", "smack", "audit"
1005           and "uefi-secureboot". The test may be negated by prepending an
1006           exclamation mark.
1007
1008       ConditionCapability=
1009           Check whether the given capability exists in the capability
1010           bounding set of the service manager (i.e. this does not check
1011           whether capability is actually available in the permitted or
1012           effective sets, see capabilities(7) for details). Pass a capability
1013           name such as "CAP_MKNOD", possibly prefixed with an exclamation
1014           mark to negate the check.
1015
1016       ConditionACPower=
1017           Check whether the system has AC power, or is exclusively battery
1018           powered at the time of activation of the unit. This takes a boolean
1019           argument. If set to "true", the condition will hold only if at
1020           least one AC connector of the system is connected to a power
1021           source, or if no AC connectors are known. Conversely, if set to
1022           "false", the condition will hold only if there is at least one AC
1023           connector known and all AC connectors are disconnected from a power
1024           source.
1025
1026       ConditionNeedsUpdate=
1027           Takes one of /var or /etc as argument, possibly prefixed with a "!"
1028           (to invert the condition). This condition may be used to
1029           conditionalize units on whether the specified directory requires an
1030           update because /usr's modification time is newer than the stamp
1031           file .updated in the specified directory. This is useful to
1032           implement offline updates of the vendor operating system resources
1033           in /usr that require updating of /etc or /var on the next following
1034           boot. Units making use of this condition should order themselves
1035           before systemd-update-done.service(8), to make sure they run before
1036           the stamp file's modification time gets reset indicating a
1037           completed update.
1038
1039           If the systemd.condition-needs-update= option is specified on the
1040           kernel command line (taking a boolean), it will override the result
1041           of this condition check, taking precedence over any file
1042           modification time checks. If it is used systemd-update-done.service
1043           will not have immediate effect on any following
1044           ConditionNeedsUpdate= checks, until the system is rebooted where
1045           the kernel command line option is not specified anymore.
1046
1047       ConditionFirstBoot=
1048           Takes a boolean argument. This condition may be used to
1049           conditionalize units on whether the system is booting up with an
1050           unpopulated /etc directory (specifically: an /etc with no
1051           /etc/machine-id). This may be used to populate /etc on the first
1052           boot after factory reset, or when a new system instance boots up
1053           for the first time.
1054
1055           If the systemd.condition-first-boot= option is specified on the
1056           kernel command line (taking a boolean), it will override the result
1057           of this condition check, taking precedence over /etc/machine-id
1058           existence checks.
1059
1060       ConditionPathExists=
1061           Check for the exists of a file. If the specified absolute path name
1062           does not exist, the condition will fail. If the absolute path name
1063           passed to ConditionPathExists= is prefixed with an exclamation mark
1064           ("!"), the test is negated, and the unit is only started if the
1065           path does not exist.
1066
1067       ConditionPathExistsGlob=
1068           ConditionPathExistsGlob= is similar to ConditionPathExists=, but
1069           checks for the existence of at least one file or directory matching
1070           the specified globbing pattern.
1071
1072       ConditionPathIsDirectory=
1073           ConditionPathIsDirectory= is similar to ConditionPathExists= but
1074           verifies that a certain path exists and is a directory.
1075
1076       ConditionPathIsSymbolicLink=
1077           ConditionPathIsSymbolicLink= is similar to ConditionPathExists= but
1078           verifies that a certain path exists and is a symbolic link.
1079
1080       ConditionPathIsMountPoint=
1081           ConditionPathIsMountPoint= is similar to ConditionPathExists= but
1082           verifies that a certain path exists and is a mount point.
1083
1084       ConditionPathIsReadWrite=
1085           ConditionPathIsReadWrite= is similar to ConditionPathExists= but
1086           verifies that the underlying file system is readable and writable
1087           (i.e. not mounted read-only).
1088
1089       ConditionPathIsEncrypted=
1090           ConditionPathIsEncrypted= is similar to ConditionPathExists= but
1091           verifies that the underlying file system's backing block device is
1092           encrypted using dm-crypt/LUKS. Note that this check does not cover
1093           ext4 per-directory encryption, and only detects block level
1094           encryption. Moreover, if the specified path resides on a file
1095           system on top of a loopback block device, only encryption above the
1096           loopback device is detected. It is not detected whether the file
1097           system backing the loopback block device is encrypted.
1098
1099       ConditionDirectoryNotEmpty=
1100           ConditionDirectoryNotEmpty= is similar to ConditionPathExists= but
1101           verifies that a certain path exists and is a non-empty directory.
1102
1103       ConditionFileNotEmpty=
1104           ConditionFileNotEmpty= is similar to ConditionPathExists= but
1105           verifies that a certain path exists and refers to a regular file
1106           with a non-zero size.
1107
1108       ConditionFileIsExecutable=
1109           ConditionFileIsExecutable= is similar to ConditionPathExists= but
1110           verifies that a certain path exists, is a regular file, and marked
1111           executable.
1112
1113       ConditionUser=
1114           ConditionUser= takes a numeric "UID", a UNIX user name, or the
1115           special value "@system". This condition may be used to check
1116           whether the service manager is running as the given user. The
1117           special value "@system" can be used to check if the user id is
1118           within the system user range. This option is not useful for system
1119           services, as the system manager exclusively runs as the root user,
1120           and thus the test result is constant.
1121
1122       ConditionGroup=
1123           ConditionGroup= is similar to ConditionUser= but verifies that the
1124           service manager's real or effective group, or any of its auxiliary
1125           groups, match the specified group or GID. This setting does not
1126           support the special value "@system".
1127
1128       ConditionControlGroupController=
1129           Verify that the given cgroup controller (eg.  "cpu") is available
1130           for use on the system. For example, a particular controller may not
1131           be available if it was disabled on the kernel command line with
1132           cgroup_disable=controller. Multiple controllers may be passed with
1133           a space separating them; in this case the condition will only pass
1134           if all listed controllers are available for use. Controllers
1135           unknown to systemd are ignored. Valid controllers are "cpu",
1136           "cpuacct", "io", "blkio", "memory", "devices", and "pids".
1137
1138       ConditionMemory=
1139           Verify that the specified amount of system memory is available to
1140           the current system. Takes a memory size in bytes as argument,
1141           optionally prefixed with a comparison operator "<", "<=", "=",
1142           "!=", ">=", ">". On bare-metal systems compares the amount of
1143           physical memory in the system with the specified size, adhering to
1144           the specified comparison operator. In containers compares the
1145           amount of memory assigned to the container instead.
1146
1147       ConditionCPUs=
1148           Verify that the specified number of CPUs is available to the
1149           current system. Takes a number of CPUs as argument, optionally
1150           prefixed with a comparison operator "<", "<=", "=", "!=", ">=",
1151           ">". Compares the number of CPUs in the CPU affinity mask
1152           configured of the service manager itself with the specified number,
1153           adhering to the specified comparison operator. On physical systems
1154           the number of CPUs in the affinity mask of the service manager
1155           usually matches the number of physical CPUs, but in special and
1156           virtual environments might differ. In particular, in containers the
1157           affinity mask usually matches the number of CPUs assigned to the
1158           container and not the physically available ones.
1159
1160       AssertArchitecture=, AssertVirtualization=, AssertHost=,
1161       AssertKernelCommandLine=, AssertKernelVersion=, AssertSecurity=,
1162       AssertCapability=, AssertACPower=, AssertNeedsUpdate=,
1163       AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=,
1164       AssertPathIsDirectory=, AssertPathIsSymbolicLink=,
1165       AssertPathIsMountPoint=, AssertPathIsReadWrite=,
1166       AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable=,
1167       AssertUser=, AssertGroup=, AssertControlGroupController=
1168           Similar to the ConditionArchitecture=, ConditionVirtualization=,
1169           ..., condition settings described above, these settings add
1170           assertion checks to the start-up of the unit. However, unlike the
1171           conditions settings, any assertion setting that is not met results
1172           in failure of the start job (which means this is logged loudly).
1173           Note that hitting a configured assertion does not cause the unit to
1174           enter the "failed" state (or in fact result in any state change of
1175           the unit), it affects only the job queued for it. Use assertion
1176           expressions for units that cannot operate when specific
1177           requirements are not met, and when this is something the
1178           administrator or user should look into.
1179

MAPPING OF UNIT PROPERTIES TO THEIR INVERSES

1181       Unit settings that create a relationship with a second unit usually
1182       show up in properties of both units, for example in systemctl show
1183       output. In some cases the name of the property is the same as the name
1184       of the configuration setting, but not always. This table lists the
1185       properties that are shown on two units which are connected through some
1186       dependency, and shows which property on "source" unit corresponds to
1187       which property on the "target" unit.
1188
1189       Table 3.  Forward and reverse unit properties
1190       ┌──────────────────────┬───────────────────────┬─────────────────────────────────┐
1191"Forward"             "Reverse"             Where used                      
1192property              property              │                                 │
1193       ├──────────────────────┼───────────────────────┼─────────────────────────────────┤
1194Before=After=                │                                 │
1195       ├──────────────────────┼───────────────────────┤ [Unit] section                  │
1196After=Before=               │                                 │
1197       ├──────────────────────┼───────────────────────┼─────────────────┬───────────────┤
1198Requires=RequiredBy=           │ [Unit] section  │ [Install]     │
1199       │                      │                       │                 │ section       │
1200       ├──────────────────────┼───────────────────────┼─────────────────┼───────────────┤
1201Wants=WantedBy=             │ [Unit] section  │ [Install]     │
1202       │                      │                       │                 │ section       │
1203       ├──────────────────────┼───────────────────────┼─────────────────┼───────────────┤
1204PartOf=ConsistsOf=           │ [Unit] section  │ an automatic  │
1205       │                      │                       │                 │ property      │
1206       ├──────────────────────┼───────────────────────┼─────────────────┼───────────────┤
1207BindsTo=BoundBy=              │ [Unit] section  │ an automatic  │
1208       │                      │                       │                 │ property      │
1209       ├──────────────────────┼───────────────────────┼─────────────────┼───────────────┤
1210Requisite=RequisiteOf=          │ [Unit] section  │ an automatic  │
1211       │                      │                       │                 │ property      │
1212       ├──────────────────────┼───────────────────────┼─────────────────┴───────────────┤
1213Triggers=TriggeredBy=          │ Automatic properties, see notes │
1214       │                      │                       │ below                           │
1215       ├──────────────────────┼───────────────────────┼─────────────────┬───────────────┤
1216Conflicts=ConflictedBy=         │ [Unit] section  │ an automatic  │
1217       │                      │                       │                 │ property      │
1218       ├──────────────────────┼───────────────────────┼─────────────────┴───────────────┤
1219PropagatesReloadTo=ReloadPropagatedFrom= │                                 │
1220       ├──────────────────────┼───────────────────────┤ [Unit] section                  │
1221ReloadPropagatedFrom=PropagatesReloadTo=   │                                 │
1222       ├──────────────────────┼───────────────────────┼─────────────────┬───────────────┤
1223Following=            │ n/a                   │ An automatic    │               │
1224       │                      │                       │ property        │               │
1225       └──────────────────────┴───────────────────────┴─────────────────┴───────────────┘
1226
1227       Note: WantedBy= and RequiredBy= are used in the [Install] section to
1228       create symlinks in .wants/ and .requires/ directories. They cannot be
1229       used directly as a unit configuration setting.
1230
1231       Note: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= are created
1232       implicitly along with their reverses and cannot be specified directly.
1233
1234       Note: Triggers= is created implicitly between a socket, path unit, or
1235       an automount unit, and the unit they activate. By default a unit with
1236       the same name is triggered, but this can be overridden using Sockets=,
1237       Service=, and Unit= settings. See systemd.service(5),
1238       systemd.socket(5), systemd.path(5), and systemd.automount(5) for
1239       details.  TriggeredBy= is created implicitly on the triggered unit.
1240
1241       Note: Following= is used to group device aliases and points to the
1242       "primary" device unit that systemd is using to track device state,
1243       usually corresponding to a sysfs path. It does not show up in the
1244       "target" unit.
1245

[INSTALL] SECTION OPTIONS

1247       Unit files may include an [Install] section, which carries installation
1248       information for the unit. This section is not interpreted by systemd(1)
1249       during runtime; it is used by the enable and disable commands of the
1250       systemctl(1) tool during installation of a unit.
1251
1252       Alias=
1253           A space-separated list of additional names this unit shall be
1254           installed under. The names listed here must have the same suffix
1255           (i.e. type) as the unit filename. This option may be specified more
1256           than once, in which case all listed names are used. At installation
1257           time, systemctl enable will create symlinks from these names to the
1258           unit filename. Note that not all unit types support such alias
1259           names, and this setting is not supported for them. Specifically,
1260           mount, slice, swap, and automount units do not support aliasing.
1261
1262       WantedBy=, RequiredBy=
1263           This option may be used more than once, or a space-separated list
1264           of unit names may be given. A symbolic link is created in the
1265           .wants/ or .requires/ directory of each of the listed units when
1266           this unit is installed by systemctl enable. This has the effect
1267           that a dependency of type Wants= or Requires= is added from the
1268           listed unit to the current unit. The primary result is that the
1269           current unit will be started when the listed unit is started. See
1270           the description of Wants= and Requires= in the [Unit] section for
1271           details.
1272
1273           WantedBy=foo.service in a service bar.service is mostly equivalent
1274           to Alias=foo.service.wants/bar.service in the same file. In case of
1275           template units, systemctl enable must be called with an instance
1276           name, and this instance will be added to the .wants/ or .requires/
1277           list of the listed unit. E.g.  WantedBy=getty.target in a service
1278           getty@.service will result in systemctl enable getty@tty2.service
1279           creating a getty.target.wants/getty@tty2.service link to
1280           getty@.service.
1281
1282       Also=
1283           Additional units to install/deinstall when this unit is
1284           installed/deinstalled. If the user requests
1285           installation/deinstallation of a unit with this option configured,
1286           systemctl enable and systemctl disable will automatically
1287           install/uninstall units listed in this option as well.
1288
1289           This option may be used more than once, or a space-separated list
1290           of unit names may be given.
1291
1292       DefaultInstance=
1293           In template unit files, this specifies for which instance the unit
1294           shall be enabled if the template is enabled without any explicitly
1295           set instance. This option has no effect in non-template unit files.
1296           The specified string must be usable as instance identifier.
1297
1298       The following specifiers are interpreted in the Install section: %n,
1299       %N, %p, %i, %j, %g, %G, %U, %u, %m, %H, %b, %v. For their meaning see
1300       the next section.
1301

SPECIFIERS

1303       Many settings resolve specifiers which may be used to write generic
1304       unit files referring to runtime or unit parameters that are replaced
1305       when the unit files are loaded. Specifiers must be known and resolvable
1306       for the setting to be valid. The following specifiers are understood:
1307
1308       Table 4. Specifiers available in unit files
1309       ┌──────────┬─────────────────────┬────────────────────────┐
1310Specifier Meaning             Details                
1311       ├──────────┼─────────────────────┼────────────────────────┤
1312       │"%a"      │ Architecture        │ A short string         │
1313       │          │                     │ identifying the        │
1314       │          │                     │ architecture of the    │
1315       │          │                     │ local system. A        │
1316       │          │                     │ string such as x86,    │
1317       │          │                     │ x86-64 or arm64.       │
1318       │          │                     │ See the                │
1319       │          │                     │ architectures          │
1320       │          │                     │ defined for            │
1321       │          │                     │ ConditionArchitecture=
1322       │          │                     │ above for a full       │
1323       │          │                     │ list.                  │
1324       ├──────────┼─────────────────────┼────────────────────────┤
1325       │"%b"      │ Boot ID             │ The boot ID of the     │
1326       │          │                     │ running system,        │
1327       │          │                     │ formatted as string.   │
1328       │          │                     │ See random(4) for more │
1329       │          │                     │ information.           │
1330       ├──────────┼─────────────────────┼────────────────────────┤
1331       │"%B"      │ Operating system    │ The operating system   │
1332       │          │ build ID            │ build identifier of    │
1333       │          │                     │ the running system, as │
1334       │          │                     │ read from the          │
1335       │          │                     │ BUILD_ID= field of     │
1336       │          │                     │ /etc/os-release. If    │
1337       │          │                     │ not set, resolves to   │
1338       │          │                     │ an empty string. See   │
1339       │          │                     │ os-release(5) for more │
1340       │          │                     │ information.           │
1341       ├──────────┼─────────────────────┼────────────────────────┤
1342       │"%C"      │ Cache directory     │ This is either         │
1343       │          │ root                │ /var/cache (for the    │
1344       │          │                     │ system manager) or the │
1345       │          │                     │ path "$XDG_CACHE_HOME" │
1346       │          │                     │ resolves to (for user  │
1347       │          │                     │ managers).             │
1348       ├──────────┼─────────────────────┼────────────────────────┤
1349       │"%E"      │ Configuration       │ This is either /etc    │
1350       │          │ directory root      │ (for the system        │
1351       │          │                     │ manager) or the path   │
1352       │          │                     │ "$XDG_CONFIG_HOME"     │
1353       │          │                     │ resolves to (for user  │
1354       │          │                     │ managers).             │
1355       ├──────────┼─────────────────────┼────────────────────────┤
1356       │"%f"      │ Unescaped filename  │ This is either the     │
1357       │          │                     │ unescaped instance     │
1358       │          │                     │ name (if applicable)   │
1359       │          │                     │ with / prepended (if   │
1360       │          │                     │ applicable), or the    │
1361       │          │                     │ unescaped prefix name  │
1362       │          │                     │ prepended with /. This │
1363       │          │                     │ implements unescaping  │
1364       │          │                     │ according to the rules │
1365       │          │                     │ for escaping absolute  │
1366       │          │                     │ file system paths      │
1367       │          │                     │ discussed above.       │
1368       ├──────────┼─────────────────────┼────────────────────────┤
1369       │"%h"      │ User home directory │ This is the home       │
1370       │          │                     │ directory of the user
1371       │          │                     │ running the service
1372       │          │                     │ manager instance. In   │
1373       │          │                     │ case of the system     │
1374       │          │                     │ manager this resolves  │
1375       │          │                     │ to "/root".            │
1376       │          │                     │                        │
1377       │          │                     │ Note that this setting │
1378       │          │                     │ is not influenced by   │
1379       │          │                     │ the User= setting      │
1380       │          │                     │ configurable in the    │
1381       │          │                     │ [Service] section of   │
1382       │          │                     │ the service unit.      │
1383       ├──────────┼─────────────────────┼────────────────────────┤
1384       │"%H"      │ Host name           │ The hostname of the    │
1385       │          │                     │ running system at the  │
1386       │          │                     │ point in time the unit │
1387       │          │                     │ configuration is       │
1388       │          │                     │ loaded.                │
1389       ├──────────┼─────────────────────┼────────────────────────┤
1390       │"%l"      │ Short host name     │ The hostname of the    │
1391       │          │                     │ running system at the  │
1392       │          │                     │ point in time the unit │
1393       │          │                     │ configuration is       │
1394       │          │                     │ loaded, truncated at   │
1395       │          │                     │ the first dot to       │
1396       │          │                     │ remove any domain      │
1397       │          │                     │ component.             │
1398       ├──────────┼─────────────────────┼────────────────────────┤
1399       │"%i"      │ Instance name       │ For instantiated units │
1400       │          │                     │ this is the string     │
1401       │          │                     │ between the first "@"  │
1402       │          │                     │ character and the type │
1403       │          │                     │ suffix. Empty for      │
1404       │          │                     │ non-instantiated       │
1405       │          │                     │ units.                 │
1406       ├──────────┼─────────────────────┼────────────────────────┤
1407       │"%I"      │ Unescaped instance  │ Same as "%i", but with │
1408       │          │ name                │ escaping undone.       │
1409       ├──────────┼─────────────────────┼────────────────────────┤
1410       │"%j"      │ Final component of  │ This is the string     │
1411       │          │ the prefix          │ between the last "-"   │
1412       │          │                     │ and the end of the     │
1413       │          │                     │ prefix name. If there  │
1414       │          │                     │ is no "-", this is the │
1415       │          │                     │ same as "%p".          │
1416       ├──────────┼─────────────────────┼────────────────────────┤
1417       │"%J"      │ Unescaped final     │ Same as "%j", but with │
1418       │          │ component of the    │ escaping undone.       │
1419       │          │ prefix              │                        │
1420       ├──────────┼─────────────────────┼────────────────────────┤
1421       │"%L"      │ Log directory root  │ This is either         │
1422       │          │                     │ /var/log (for the      │
1423       │          │                     │ system manager) or the │
1424       │          │                     │ path                   │
1425       │          │                     │ "$XDG_CONFIG_HOME"     │
1426       │          │                     │ resolves to with /log  │
1427       │          │                     │ appended (for user     │
1428       │          │                     │ managers).             │
1429       ├──────────┼─────────────────────┼────────────────────────┤
1430       │"%m"      │ Machine ID          │ The machine ID of the  │
1431       │          │                     │ running system,        │
1432       │          │                     │ formatted as string.   │
1433       │          │                     │ See machine-id(5) for  │
1434       │          │                     │ more information.      │
1435       ├──────────┼─────────────────────┼────────────────────────┤
1436       │"%o"      │ Operating system ID │ The operating system   │
1437       │          │                     │ identifier of the      │
1438       │          │                     │ running system, as     │
1439       │          │                     │ read from the ID=
1440       │          │                     │ field of               │
1441       │          │                     │ /etc/os-release. See   │
1442       │          │                     │ os-release(5) for more │
1443       │          │                     │ information.           │
1444       ├──────────┼─────────────────────┼────────────────────────┤
1445       │"%n"      │ Full unit name      │                        │
1446       ├──────────┼─────────────────────┼────────────────────────┤
1447       │"%N"      │ Full unit name      │ Same as "%n", but with │
1448       │          │                     │ the type suffix        │
1449       │          │                     │ removed.               │
1450       ├──────────┼─────────────────────┼────────────────────────┤
1451       │"%p"      │ Prefix name         │ For instantiated       │
1452       │          │                     │ units, this refers to  │
1453       │          │                     │ the string before the  │
1454       │          │                     │ first "@" character of │
1455       │          │                     │ the unit name. For     │
1456       │          │                     │ non-instantiated       │
1457       │          │                     │ units, same as "%N".   │
1458       ├──────────┼─────────────────────┼────────────────────────┤
1459       │"%P"      │ Unescaped prefix    │ Same as "%p", but with │
1460       │          │ name                │ escaping undone.       │
1461       ├──────────┼─────────────────────┼────────────────────────┤
1462       │"%s"      │ User shell          │ This is the shell of   │
1463       │          │                     │ the user running the   │
1464       │          │                     │ service manager        │
1465       │          │                     │ instance. In case of   │
1466       │          │                     │ the system manager     │
1467       │          │                     │ this resolves to       │
1468       │          │                     │ "/bin/sh".             │
1469       ├──────────┼─────────────────────┼────────────────────────┤
1470       │"%S"      │ State directory     │ This is either         │
1471       │          │ root                │ /var/lib (for the      │
1472       │          │                     │ system manager) or the │
1473       │          │                     │ path                   │
1474       │          │                     │ "$XDG_CONFIG_HOME"     │
1475       │          │                     │ resolves to (for user  │
1476       │          │                     │ managers).             │
1477       ├──────────┼─────────────────────┼────────────────────────┤
1478       │"%t"      │ Runtime directory   │ This is either /run    │
1479       │          │ root                │ (for the system        │
1480       │          │                     │ manager) or the path   │
1481       │          │                     │ "$XDG_RUNTIME_DIR"     │
1482       │          │                     │ resolves to (for user  │
1483       │          │                     │ managers).             │
1484       ├──────────┼─────────────────────┼────────────────────────┤
1485       │"%T"      │ Directory for       │ This is either /tmp or │
1486       │          │ temporary files     │ the path "$TMPDIR",    │
1487       │          │                     │ "$TEMP" or "$TMP" are  │
1488       │          │                     │ set to.                │
1489       ├──────────┼─────────────────────┼────────────────────────┤
1490       │"%g"      │ User group          │ This is the name of    │
1491       │          │                     │ the group running the  │
1492       │          │                     │ service manager        │
1493       │          │                     │ instance. In case of   │
1494       │          │                     │ the system manager     │
1495       │          │                     │ this resolves to       │
1496       │          │                     │ "root".                │
1497       ├──────────┼─────────────────────┼────────────────────────┤
1498       │"%G"      │ User GID            │ This is the numeric    │
1499       │          │                     │ GID of the user        │
1500       │          │                     │ running the service    │
1501       │          │                     │ manager instance. In   │
1502       │          │                     │ case of the system     │
1503       │          │                     │ manager this resolves  │
1504       │          │                     │ to "0".                │
1505       ├──────────┼─────────────────────┼────────────────────────┤
1506       │"%u"      │ User name           │ This is the name of    │
1507       │          │                     │ the user running the
1508       │          │                     │ service manager
1509       │          │                     │ instance. In case of   │
1510       │          │                     │ the system manager     │
1511       │          │                     │ this resolves to       │
1512       │          │                     │ "root".                │
1513       │          │                     │                        │
1514       │          │                     │ Note that this setting │
1515       │          │                     │ is not influenced by   │
1516       │          │                     │ the User= setting      │
1517       │          │                     │ configurable in the    │
1518       │          │                     │ [Service] section of   │
1519       │          │                     │ the service unit.      │
1520       ├──────────┼─────────────────────┼────────────────────────┤
1521       │"%U"      │ User UID            │ This is the numeric    │
1522       │          │                     │ UID of the user
1523       │          │                     │ running the service
1524       │          │                     │ manager instance. In   │
1525       │          │                     │ case of the system     │
1526       │          │                     │ manager this resolves  │
1527       │          │                     │ to "0".                │
1528       │          │                     │                        │
1529       │          │                     │ Note that this setting │
1530       │          │                     │ is not influenced by   │
1531       │          │                     │ the User= setting      │
1532       │          │                     │ configurable in the    │
1533       │          │                     │ [Service] section of   │
1534       │          │                     │ the service unit.      │
1535       ├──────────┼─────────────────────┼────────────────────────┤
1536       │"%v"      │ Kernel release      │ Identical to uname -r  
1537       │          │                     │ output.                │
1538       ├──────────┼─────────────────────┼────────────────────────┤
1539       │"%V"      │ Directory for       │ This is either         │
1540       │          │ larger and          │ /var/tmp or the path   │
1541       │          │ persistent          │ "$TMPDIR", "$TEMP" or  │
1542       │          │ temporary files     │ "$TMP" are set to.     │
1543       ├──────────┼─────────────────────┼────────────────────────┤
1544       │"%w"      │ Operating system    │ The operating system   │
1545       │          │ version ID          │ version identifier of  │
1546       │          │                     │ the running system, as │
1547       │          │                     │ read from the          │
1548       │          │                     │ VERSION_ID= field of   │
1549       │          │                     │ /etc/os-release. If    │
1550       │          │                     │ not set, resolves to   │
1551       │          │                     │ an empty string. See   │
1552       │          │                     │ os-release(5) for more │
1553       │          │                     │ information.           │
1554       ├──────────┼─────────────────────┼────────────────────────┤
1555       │"%W"      │ Operating system    │ The operating system   │
1556       │          │ variant ID          │ variant identifier of  │
1557       │          │                     │ the running system, as │
1558       │          │                     │ read from the          │
1559       │          │                     │ VARIANT_ID= field of   │
1560       │          │                     │ /etc/os-release. If    │
1561       │          │                     │ not set, resolves to   │
1562       │          │                     │ an empty string. See   │
1563       │          │                     │ os-release(5) for more │
1564       │          │                     │ information.           │
1565       ├──────────┼─────────────────────┼────────────────────────┤
1566       │"%%"      │ Single percent sign │ Use "%%" in place of   │
1567       │          │                     │ "%" to specify a       │
1568       │          │                     │ single percent sign.   │
1569       └──────────┴─────────────────────┴────────────────────────┘
1570

EXAMPLES

1572       Example 1. Allowing units to be enabled
1573
1574       The following snippet (highlighted) allows a unit (e.g.  foo.service)
1575       to be enabled via systemctl enable:
1576
1577           [Unit]
1578           Description=Foo
1579
1580           [Service]
1581           ExecStart=/usr/sbin/foo-daemon
1582
1583           [Install]
1584           WantedBy=multi-user.target
1585
1586       After running systemctl enable, a symlink
1587       /etc/systemd/system/multi-user.target.wants/foo.service linking to the
1588       actual unit will be created. It tells systemd to pull in the unit when
1589       starting multi-user.target. The inverse systemctl disable will remove
1590       that symlink again.
1591
1592       Example 2. Overriding vendor settings
1593
1594       There are two methods of overriding vendor settings in unit files:
1595       copying the unit file from /usr/lib/systemd/system to
1596       /etc/systemd/system and modifying the chosen settings. Alternatively,
1597       one can create a directory named unit.d/ within /etc/systemd/system and
1598       place a drop-in file name.conf there that only changes the specific
1599       settings one is interested in. Note that multiple such drop-in files
1600       are read if present, processed in lexicographic order of their
1601       filename.
1602
1603       The advantage of the first method is that one easily overrides the
1604       complete unit, the vendor unit is not parsed at all anymore. It has the
1605       disadvantage that improvements to the unit file by the vendor are not
1606       automatically incorporated on updates.
1607
1608       The advantage of the second method is that one only overrides the
1609       settings one specifically wants, where updates to the unit by the
1610       vendor automatically apply. This has the disadvantage that some future
1611       updates by the vendor might be incompatible with the local changes.
1612
1613       This also applies for user instances of systemd, but with different
1614       locations for the unit files. See the section on unit load paths for
1615       further details.
1616
1617       Suppose there is a vendor-supplied unit
1618       /usr/lib/systemd/system/httpd.service with the following contents:
1619
1620           [Unit]
1621           Description=Some HTTP server
1622           After=remote-fs.target sqldb.service
1623           Requires=sqldb.service
1624           AssertPathExists=/srv/webserver
1625
1626           [Service]
1627           Type=notify
1628           ExecStart=/usr/sbin/some-fancy-httpd-server
1629           Nice=5
1630
1631           [Install]
1632           WantedBy=multi-user.target
1633
1634       Now one wants to change some settings as an administrator: firstly, in
1635       the local setup, /srv/webserver might not exist, because the HTTP
1636       server is configured to use /srv/www instead. Secondly, the local
1637       configuration makes the HTTP server also depend on a memory cache
1638       service, memcached.service, that should be pulled in (Requires=) and
1639       also be ordered appropriately (After=). Thirdly, in order to harden the
1640       service a bit more, the administrator would like to set the PrivateTmp=
1641       setting (see systemd.exec(5) for details). And lastly, the
1642       administrator would like to reset the niceness of the service to its
1643       default value of 0.
1644
1645       The first possibility is to copy the unit file to
1646       /etc/systemd/system/httpd.service and change the chosen settings:
1647
1648           [Unit]
1649           Description=Some HTTP server
1650           After=remote-fs.target sqldb.service memcached.service
1651           Requires=sqldb.service memcached.service
1652           AssertPathExists=/srv/www
1653
1654           [Service]
1655           Type=notify
1656           ExecStart=/usr/sbin/some-fancy-httpd-server
1657           Nice=0
1658           PrivateTmp=yes
1659
1660           [Install]
1661           WantedBy=multi-user.target
1662
1663       Alternatively, the administrator could create a drop-in file
1664       /etc/systemd/system/httpd.service.d/local.conf with the following
1665       contents:
1666
1667           [Unit]
1668           After=memcached.service
1669           Requires=memcached.service
1670           # Reset all assertions and then re-add the condition we want
1671           AssertPathExists=
1672           AssertPathExists=/srv/www
1673
1674           [Service]
1675           Nice=0
1676           PrivateTmp=yes
1677
1678       Note that for drop-in files, if one wants to remove entries from a
1679       setting that is parsed as a list (and is not a dependency), such as
1680       AssertPathExists= (or e.g.  ExecStart= in service units), one needs to
1681       first clear the list before re-adding all entries except the one that
1682       is to be removed. Dependencies (After=, etc.) cannot be reset to an
1683       empty list, so dependencies can only be added in drop-ins. If you want
1684       to remove dependencies, you have to override the entire unit.
1685

SEE ALSO

1687       systemd(1), systemctl(1), systemd-system.conf(5), systemd.special(7),
1688       systemd.service(5), systemd.socket(5), systemd.device(5),
1689       systemd.mount(5), systemd.automount(5), systemd.swap(5),
1690       systemd.target(5), systemd.path(5), systemd.timer(5), systemd.scope(5),
1691       systemd.slice(5), systemd.time(7), systemd-analyze(1), capabilities(7),
1692       systemd.directives(7), uname(1)
1693

NOTES

1695        1. Interface Portability and Stability Promise
1696           https://systemd.io/PORTABILITY_AND_STABILITY/
1697
1698
1699
1700systemd 246                                                    SYSTEMD.UNIT(5)
Impressum