X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fsystemd.unit.xml;h=3236bfa7416f07670294827c0984ba6df5df9f6f;hp=8a402d053d9a6e100cf60e2bd12c62fb12086981;hb=b2896c905bef7be7ed9a760d9d61aa6ad0f614a3;hpb=af62c704053b5d34672497eb5bdc4764ebbb5f4f
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 8a402d053..3236bfa74 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -8,16 +8,16 @@
Copyright 2010 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.
systemd is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
+ Lesser General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see .
-->
@@ -56,7 +56,8 @@
systemd.swap,
systemd.target,
systemd.path,
- systemd.timer
+ systemd.timer,
+ systemd.snapshot
@@ -70,17 +71,17 @@
systemd1. The
syntax is inspired by XDG
- Desktop Entry Specificiation.desktop files, which are in turn
+ Desktop Entry Specification .desktop files, which are in turn
inspired by Microsoft Windows
.ini files.
This man pages lists the common configuration
- options of the all unit types. These options need to
+ options of all the unit types. These options need to
be configured in the [Unit] resp. [Install]
section of the unit files.In addition to the generic [Unit] and [Install]
- sections described here each unit should have a
+ sections described here, each unit should have a
type-specific section, e.g. [Service] for a service
unit. See the respective man pages for more
information.
@@ -94,7 +95,7 @@
additional information in the unit files.
Boolean arguments used in unit files can be
- written in various forms. For positive settings the
+ written in various formats. For positive settings the
strings , ,
and are
equivalent. For negative settings the strings
@@ -102,13 +103,27 @@
and are
equivalent.
+ Time span values encoded in unit files can be
+ written in various formats. A stand-alone number
+ specifies a time in seconds. If suffixed with a time
+ unit, the unit is honored. A concatenation of
+ multiple values with units is supported, in which case
+ the values are added up. Example: "50" refers to 50
+ seconds; "2min 200ms" refers to 2 minutes plus 200
+ milliseconds, i.e. 120200ms. The following time units
+ are understood: s, min, h, d, w, ms, us.
+
Empty lines and lines starting with # or ; are
- ignored. This may be used for commenting.
+ ignored. This may be used for commenting. Lines ending
+ in a backslash are concatenated with the following
+ line while reading and the backslash is replaced by a
+ space character. This may be used to wrap long lines.
If a line starts with
- followed by a file name the specified file will be
- read as if its contents where listed in place of the
- directive.
+ followed by a file name, the specified file will be
+ parsed at this point. Make sure that the file that is
+ included has the appropriate section headers before
+ any directives.
Along with a unit file
foo.service a directory
@@ -122,10 +137,13 @@
Wanted= see below. The preferred
way to create symlinks in the
.wants/ directory of a service is
- with the
- systemd-install1
+ with the enable command of the
+ systemctl1
tool which reads information from the [Install]
- section of unit files. (See below.)
+ section of unit files. (See below.) A similar
+ functionality exists for Requires=
+ type dependencies as well, the directory suffix is
+ .requires/ in this case.
Note that while systemd offers a flexible
dependency system between units it is recommended to
@@ -134,6 +152,138 @@
activation which makes dependencies implicit, which
both results in a simpler and more flexible
system.
+
+ Some unit names reflect paths existing in the
+ file system name space. Example: a device unit
+ dev-sda.device refers to a device
+ with the device node /dev/sda in
+ the file system namespace. If this applies a special
+ way to escape the path name is used, so that the
+ result is usable as part of a file name. Basically,
+ given a path, "/" is replaced by "-", and all
+ unprintable characters and the "-" are replaced by
+ C-style "\x20" escapes. The root directory "/" is
+ encoded as single dash, while otherwise the initial
+ and ending "/" is removed from all paths during
+ transformation. This escaping is reversible.
+
+ Optionally, units may be instantiated from a
+ template file at runtime. This allows creation of
+ multiple units from a single configuration file. If
+ systemd looks for a unit configuration file it will
+ first search for the literal unit name in the
+ filesystem. If that yields no success and the unit
+ name contains an @ character, systemd will look for a
+ unit template that shares the same name but with the
+ instance string (i.e. the part between the @ character
+ and the suffix) removed. Example: if a service
+ getty@tty3.service is requested
+ and no file by that name is found, systemd will look
+ for getty@.service and
+ instantiate a service from that configuration file if
+ it is found.
+
+ To refer to the instance string from
+ within the configuration file you may use the special
+ %i specifier in many of the
+ configuration options. Other specifiers exist, the
+ full list is:
+
+
+ Specifiers available in unit files
+
+
+
+
+
+
+ Specifier
+ Meaning
+ Details
+
+
+
+
+ %n
+ Full unit name
+
+
+
+ %N
+ Unescaped full unit name
+
+
+
+ %p
+ Prefix name
+ This refers to the string before the @, i.e. "getty" in the example above, where "tty3" is the instance name.
+
+
+ %P
+ Unescaped prefix name
+
+
+
+ %i
+ Instance name
+ This is the string between the @ character and the suffix.
+
+
+ %I
+ Unescaped instance name
+
+
+
+ %f
+ Unescaped file name
+ This is either the unescaped instance name (if set) with / prepended (if necessary), or the prefix name similarly prepended with /.
+
+
+ %c
+ Control group path of the unit
+
+
+
+ %r
+ Root control group path of systemd
+
+
+
+ %R
+ Parent directory of the root control group path of systemd
+
+
+
+ %t
+ Runtime socket dir
+ This is either /run (for the system manager) or $XDG_RUNTIME_DIR (for user managers).
+
+
+ %u
+ User name
+ This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.
+
+
+ %h
+ User home directory
+ This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd instance.
+
+
+
+
+
+ If a unit file is empty (i.e. has the file size
+ 0) or is symlinked to /dev/null
+ its configuration will not be loaded and it appears
+ with a load state of masked, and
+ cannot be activated. Use this as an effective way to
+ fully disable a unit, making it impossible to start it
+ even manually.
+
+ The unit file format is covered by the
+ Interface
+ Stability Promise.
@@ -144,29 +294,31 @@
dependent on the type of unit:
-
- Names=
-
- Additional names for
- this unit. The names listed here must
- have the same suffix (i.e. type) as
- the unit file name. This option may be
- specified more than once, in which
- case all listed names are used. Note
- that this option is different from the
- Alias= option from
- the [Install] section mentioned
- below. See below for details.
-
- Description=A free-form string
- describing the unit. This is intended for use
- in UIs wanting to show
- descriptive information along with the
- unit name.
+ describing the unit. This is intended
+ for use in UIs to show descriptive
+ information along with the unit
+ name.
+
+
+
+ Documentation=
+ A space separated list
+ of URIs referencing documentation for
+ this unit or its
+ configuration. Accepted are only URIs
+ of the types
+ http://,
+ https://,
+ file:,
+ info:,
+ man:. For more
+ information about the syntax of these
+ URIs see
+ uri7.
@@ -174,7 +326,7 @@
Configures requirement
dependencies on other units. If this
- units get activated the units listed
+ unit gets activated, the units listed
here will be activated as well. If one
of the other units gets deactivated or
its activation fails, this unit will
@@ -209,7 +361,6 @@
services.
-
RequiresOverridable=
@@ -218,7 +369,7 @@
Dependencies listed in
RequiresOverridable=
which cannot be fulfilled or fail to
- start are ignored iff the startup was
+ start are ignored if the startup was
explicitly requested by the user. If
the start-up was pulled in indirectly
by some dependency or automatic
@@ -227,7 +378,7 @@
must be fulfilled and otherwise the
transaction fails. Hence, this option
may be used to configure dependencies
- that are normally honoured unless the
+ that are normally honored unless the
user explicitly starts up the unit, in
which case whether they failed or not
is irrelevant.
@@ -253,7 +404,7 @@
Requires=. A unit
listed in this option will be started
if the configuring unit is. However,
- it the listed unit fails to start up
+ if the listed unit fails to start up
or cannot be added to the transaction
this has no impact on the validity of
the transaction as a whole. This is
@@ -268,20 +419,52 @@
details see above.
+
+ BindsTo=
+
+ Configures requirement
+ dependencies, very similar in style to
+ Requires=, however
+ in addition to this behaviour it also
+ declares that this unit is stopped
+ when any of the units listed suddenly
+ disappears. Units can suddenly,
+ unexpectedly disappear if a service
+ terminates on its own choice, a device
+ is unplugged or a mount point
+ unmounted without involvement of
+ systemd.
+
+
Conflicts=Configures negative
requirement dependencies. If a unit
- that has a
+ has a
Conflicts= setting
- on another unit starting the former
+ on another unit, starting the former
will stop the latter and vice
versa. Note that this setting is
independent of and orthogonal to the
After= and
Before= ordering
- dependencies.
+ dependencies.
+
+ If a unit A that conflicts with
+ a unit B is scheduled to be started at
+ the same time as B, the transaction
+ will either fail (in case both are
+ required part of the transaction) or
+ be modified to be fixed (in case one
+ or both jobs are not a required part
+ of the transaction). In the latter
+ case the job that is not the required
+ will be removed, or in case both are
+ not required the unit that conflicts
+ will be started and the unit that is
+ conflicted is
+ stopped.
@@ -293,7 +476,7 @@
foo.service
contains a setting
- and both units are being started
+ and both units are being started,
bar.service's
start-up is delayed until
foo.service is
@@ -323,7 +506,7 @@
listed unit is started. Note that when
two units with an ordering dependency
between them are shut down, the
- inverse of of the start-up order is
+ inverse of the start-up order is
applied. i.e. if a unit is configured
with After= on
another unit, the former is stopped
@@ -344,25 +527,81 @@
- RecursiveStop=
+ OnFailure=
+
+ Lists one or more
+ units that are activated when this
+ unit enters the
+ 'failed'
+ state.
+
+
+
+ PropagatesReloadTo=
+ ReloadPropagatedFrom=
+
+ Lists one or more
+ units where reload requests on the
+ unit will be propagated to/on the
+ other unit will be propagated
+ from. Issuing a reload request on a
+ unit will automatically also enqueue a
+ reload request on all units that the
+ reload request shall be propagated to
+ via these two
+ settings.
+
+
+
+ RequiresMountsFor=
+
+ Takes a space
+ separated list of paths. Automatically
+ adds dependencies of type
+ Requires= and
+ After= for all
+ mount units required to access the
+ specified path.
+
+
+
+ OnFailureIsolate=Takes a boolean
- argument. If and
- the unit stops without this being
- requested by the user all units
- depending on it will be stopped as
- well. (e.g. if a service exits or
- crashes on its own behalf, units using
- it will be stopped) Note that normally
- if a unit stops without user request
- units depending on it will not be
- terminated. Only if the user requested
- shutdown of a unit all units depending
- on the unit will be shut down as well
- and at the same time. Defaults to
+ argument. If the
+ unit listed in
+ OnFailure= will be
+ enqueued in isolation mode, i.e. all
+ units that are not its dependency will
+ be stopped. If this is set only a
+ single unit may be listed in
+ OnFailure=. Defaults
+ to
.
+
+ IgnoreOnIsolate=
+
+ Takes a boolean
+ argument. If
+ this unit will not be stopped when
+ isolating another unit. Defaults to
+ .
+
+
+
+ IgnoreOnSnapshot=
+
+ Takes a boolean
+ argument. If
+ this unit will not be included in
+ snapshots. Defaults to
+ for device and
+ snapshot units,
+ for the others.
+
+
StopWhenUnneeded=
@@ -370,35 +609,288 @@
argument. If
this unit will be stopped when it is
no longer used. Note that in order to
- minimize the work to be executed
- systemd will by default not stop units
+ minimize the work to be executed,
+ systemd will not stop units by default
unless they are conflicting with other
units, or the user explicitly
requested their shut down. If this
- option is set a unit will be
+ option is set, a unit will be
automatically cleaned up if no other
active unit requires it. Defaults to
.
- OnlyByDependency=
+ RefuseManualStart=
+ RefuseManualStop=
+
+ Takes a boolean
+ argument. If
+ this unit can only be activated
+ (resp. deactivated) indirectly. In
+ this case explicit start-up
+ (resp. termination) requested by the
+ user is denied, however if it is
+ started (resp. stopped) as a
+ dependency of another unit, start-up
+ (resp. termination) will succeed. This
+ is mostly a safety feature to ensure
+ that the user does not accidentally
+ activate units that are not intended
+ to be activated explicitly, and not
+ accidentally deactivate units that are
+ not intended to be deactivated.
+ These options default to
+ .
+
+
+
+ AllowIsolate=Takes a boolean
argument. If
- this unit may only be activated
- indirectly. In this case explicit
- start-up requested by the user is
- denied, however if it is started as
- dependency of another unit start-up
- will succeed. This is mostly a safety
- feature to ensure that the user does
- not accidently activate units that are
- not intended to be activated
- explicitly. This option defaults to
+ this unit may be used with the
+ systemctl isolate
+ command. Otherwise this will be
+ refused. It probably is a good idea to
+ leave this disabled except for target
+ units that shall be used similar to
+ runlevels in SysV init systems, just
+ as a precaution to avoid unusable
+ system states. This option defaults to
.
+
+ DefaultDependencies=
+
+ Takes a boolean
+ argument. If
+ (the default), a few default
+ dependencies will implicitly be
+ created for the unit. The actual
+ dependencies created depend on the
+ unit type. For example, for service
+ units, these dependencies ensure that
+ the service is started only after
+ basic system initialization is
+ completed and is properly terminated on
+ system shutdown. See the respective
+ man pages for details. Generally, only
+ services involved with early boot or
+ late shutdown should set this option
+ to . It is
+ highly recommended to leave this
+ option enabled for the majority of
+ common units. If set to
+ this option
+ does not disable all implicit
+ dependencies, just non-essential
+ ones.
+
+
+
+ JobTimeoutSec=
+
+ When clients are
+ waiting for a job of this unit to
+ complete, time out after the specified
+ time. If this time limit is reached
+ the job will be cancelled, the unit
+ however will not change state or even
+ enter the 'failed'
+ mode. This value defaults to 0 (job
+ timeouts disabled), except for device
+ units. NB: this timeout is independent
+ from any unit-specific timeout (for
+ example, the timeout set with
+ Timeout= in service
+ units) as the job timeout has no
+ effect on the unit itself, only on the
+ job that might be pending for it. Or
+ in other words: unit-specific timeouts
+ are useful to abort unit state
+ changes, and revert them. The job
+ timeout set with this option however
+ is useful to abort only the job
+ waiting for the unit state to
+ change.
+
+
+
+ ConditionPathExists=
+ ConditionPathExistsGlob=
+ ConditionPathIsDirectory=
+ ConditionPathIsSymbolicLink=
+ ConditionPathIsMountPoint=
+ ConditionPathIsReadWrite=
+ ConditionDirectoryNotEmpty=
+ ConditionFileIsExecutable=
+ ConditionKernelCommandLine=
+ ConditionVirtualization=
+ ConditionSecurity=
+ ConditionCapability=
+ ConditionNull=
+
+ Before starting a unit
+ verify that the specified condition is
+ true. With
+ ConditionPathExists=
+ a file existence condition can be
+ checked before a unit is started. If
+ the specified absolute path name does
+ not exist, startup of a unit will not
+ actually happen, however the unit is
+ still useful for ordering purposes in
+ this case. The condition is checked at
+ the time the queued start job is to be
+ executed. If the absolute path name
+ passed to
+ ConditionPathExists=
+ is prefixed with an exclamation mark
+ (!), the test is negated, and the unit
+ is only started if the path does not
+ exist.
+ ConditionPathExistsGlob=
+ works in a similar way, but checks for
+ the existence of at least one file or
+ directory matching the specified
+ globbing
+ pattern. ConditionPathIsDirectory=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists and is a
+ directory. ConditionPathIsSymbolicLink=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists and is a symbolic
+ link. ConditionPathIsMountPoint=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists and is a mount
+ point. ConditionPathIsReadWrite=
+ is similar to
+ ConditionPathExists=
+ but verifies whether the underlying
+ file system is read and writable
+ (i.e. not mounted
+ read-only). ConditionFileIsExecutable=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists, is a regular file and marked
+ executable.
+ ConditionDirectoryNotEmpty=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists and is a non-empty
+ directory. Similarly
+ ConditionKernelCommandLine=
+ may be used to check whether a
+ specific kernel command line option is
+ set (or if prefixed with the
+ exclamation mark unset). The argument
+ must either be a single word, or an
+ assignment (i.e. two words, separated
+ by the equality sign). In the former
+ case the kernel command line is
+ searched for the word appearing as is,
+ or as left hand side of an
+ assignment. In the latter case the
+ exact assignment is looked for with
+ right and left hand side
+ matching. ConditionVirtualization=
+ may be used to check whether the
+ system is executed in a virtualized
+ environment and optionally test
+ whether it is a specific
+ implementation. Takes either boolean
+ value to check if being executed in
+ any virtualized environment, or one of
+ vm and
+ container to test
+ against a specific type of
+ virtualization solution, or one of
+ qemu,
+ kvm,
+ vmware,
+ microsoft,
+ oracle,
+ xen,
+ bochs,
+ chroot,
+ openvz,
+ lxc,
+ lxc-libvirt,
+ systemd-nspawn to
+ test against a specific
+ implementation. If multiple
+ virtualization technologies are nested
+ only the innermost is considered. The
+ test may be negated by prepending an
+ exclamation mark.
+ ConditionSecurity=
+ may be used to check whether the given
+ security module is enabled on the
+ system. Currently the only recognized
+ value is selinux.
+ The test may be negated by prepending
+ an exclamation
+ mark. ConditionCapability=
+ may be used to check whether the given
+ capability exists in the capability
+ bounding set of the service manager
+ (i.e. this does not check whether
+ capability is actually available in
+ the permitted or effective sets, see
+ capabilities7
+ for details). Pass a capability name
+ such as CAP_MKNOD,
+ possibly prefixed with an exclamation
+ mark to negate the check. Finally,
+ ConditionNull= may
+ be used to add a constant condition
+ check value to the unit. It takes a
+ boolean argument. If set to
+ false the condition
+ will always fail, otherwise
+ succeed. If multiple conditions are
+ specified the unit will be executed if
+ all of them apply (i.e. a logical AND
+ is applied). Condition checks can be
+ prefixed with a pipe symbol (|) in
+ which case a condition becomes a
+ triggering condition. If at least one
+ triggering condition is defined for a
+ unit then the unit will be executed if
+ at least one of the triggering
+ conditions apply and all of the
+ non-triggering conditions. If you
+ prefix an argument with the pipe
+ symbol and an exclamation mark the
+ pipe symbol must be passed first, the
+ exclamation second. Except for
+ ConditionPathIsSymbolicLink=,
+ all path checks follow
+ symlinks.
+
+
+
+ SourcePath=
+ A path to a
+ configuration file this unit has been
+ generated from. This is primarily
+ useful for implementation of generator
+ tools that convert configuration from
+ an external configuration file format
+ into native unit files. Thus
+ functionality should not be used in
+ normal units.
+ Unit file may include a [Install] section, which
@@ -406,14 +898,16 @@
section is not interpreted by
systemd1
during runtime. It is used exclusively by the
- systemd-install1
+ enable and
+ disable commands of the
+ systemctl1
tool during installation of a unit:Alias=
- Additional names, this
+ Additional names this
unit shall be installed under. The
names listed here must have the same
suffix (i.e. type) as the unit file
@@ -421,44 +915,23 @@
more than once, in which case all
listed names are used. At installation
time,
- systemd-install
+ systemctl enable
will create symlinks from these names
- to the unit file name. Note that this
- is different from the
- Names= option from
- the [Unit] section mentioned above:
- The names from
- Names= apply
- unconditionally if the unit is
- loaded. The names from
- Alias= apply only
- if the unit has actually been
- installed with the
- systemd-install
- tool. Also, if systemd searches for a
- unit, it will discover symlinked alias
- names as configured with
- Alias=, but not
- names configured with
- Names= only. It is
- a common pattern to list a name in
- both options. In this case, a unit
- will be active under all names if
- installed, but also if not installed
- but requested explicitly under its
- main name.
+ to the unit file name.WantedBy=
+ RequiredBy=Installs a symlink in
the .wants/
+ resp. .requires/
subdirectory for a unit. This has the
effect that when the listed unit name
is activated the unit listing it is
activated
- to. WantedBy=foo.service
+ too. WantedBy=foo.service
in a service
bar.service is
mostly equivalent to
@@ -473,8 +946,8 @@
install when this unit is
installed. If the user requests
installation of a unit with this
- option configured
- systemd-install
+ option configured,
+ systemctl enable
will automatically install units
listed in this option as
well.
@@ -488,7 +961,6 @@
systemd1,
systemctl8,
- systemd-install1,
systemd.special7,
systemd.service5,
systemd.socket5,
@@ -498,7 +970,9 @@
systemd.swap5,
systemd.target5,
systemd.path5,
- systemd.timer5
+ systemd.timer5,
+ systemd.snapshot5,
+ capabilities7