X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fsystemd.unit.xml;h=47c50315ae941e58d5b923da3b8e89a355d37d8c;hb=ee531d949c2f62374fc109252f8cbe61c2b8ee39;hp=e54cafaabcd2f0b854b7d9e1aa7126c83170d5a5;hpb=52661efd21608dc7e0ac26b714a9254ed6180ddb;p=elogind.git
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index e54cafaab..47c50315a 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -1,6 +1,9 @@
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+
+%entities;
+]>
@@ -44,20 +47,32 @@
systemd.unit
- systemd unit configuration files
+ Unit configuration
- systemd.service,
- systemd.socket,
- systemd.device,
- systemd.mount,
- systemd.automount,
- systemd.swap,
- systemd.target,
- systemd.path,
- systemd.timer,
- systemd.snapshot
+ service.service,
+ socket.socket,
+ device.device,
+ mount.mount,
+ automount.automount,
+ swap.swap,
+ target.target,
+ path.path,
+ timer.timer,
+ snapshot.snapshot
+
+ /etc/systemd/system/*
+/run/systemd/system/*
+/usr/lib/systemd/system/*
+...
+
+
+ /etc/systemd/user/*
+/run/systemd/user/*
+/usr/lib/systemd/user/*
+...
+
@@ -66,7 +81,7 @@
A unit configuration file encodes information
about a service, a socket, a device, a mount point, an
automount point, a swap file or partition, a start-up
- target, a file system path or a timer controlled and
+ target, a file system path, or a timer controlled and
supervised by
systemd1. The
syntax is inspired by .ini files.
- This man pages lists the common configuration
+ This man page lists the common configuration
options of all the unit types. These options need to
- be configured in the [Unit] resp. [Install]
- section of the unit files.
+ be configured in the [Unit] or [Install]
+ sections 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 may have a
type-specific section, e.g. [Service] for a service
unit. See the respective man pages for more
- information.
+ information:
+ systemd.service5,
+ systemd.socket5,
+ systemd.device5,
+ systemd.mount5,
+ systemd.automount5,
+ systemd.swap5,
+ systemd.target5,
+ systemd.path5,
+ systemd.timer5,
+ systemd.snapshot5.
+
+
+ Unit files are loaded from a set of paths
+ determined during compilation, described in the next section.
+ Unit files may contain additional options on top
of those listed here. If systemd encounters an unknown
@@ -106,12 +136,14 @@
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
+ 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.
+ are understood: s, min, h, d, w, ms, us. For details
+ see
+ systemd.time7.Empty lines and lines starting with # or ; are
ignored. This may be used for commenting. Lines ending
@@ -119,35 +151,48 @@
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 were listed in place of the
- directive.
-
Along with a unit file
- foo.service a directory
+ foo.service the directory
foo.service.wants/ may exist. All
- units symlinked from such a directory are implicitly
- added as dependencies of type
+ unit files symlinked from such a directory are
+ implicitly added as dependencies of type
Wanted= to the unit. This is useful
to hook units into the start-up of other units,
- without having to modify their unit configuration
- files. For details about the semantics of
- Wanted= see below. The preferred
- way to create symlinks in the
- .wants/ directory of a service is
- with the enable command of the
+ without having to modify their unit files. For details
+ about the semantics of Wanted= see
+ below. The preferred way to create symlinks in the
+ .wants/ directory of a unit file
+ is 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.
+
+ Along with a unit file
+ foo.service a directory
+ foo.service.d/ may exist. All
+ files with the suffix .conf from
+ this directory will be parsed after the file itself is
+ parsed. This is useful to alter or add configuration
+ settings to a unit, without having to modify their
+ unit files. Make sure that the file that is included
+ has the appropriate section headers before any
+ directive.
+
+ If a line starts with
+ 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.Note that while systemd offers a flexible
dependency system between units it is recommended to
- use this functionality only sparsely and instead rely
+ use this functionality only sparingly and instead rely
on techniques such as bus-based or socket-based
- activation which makes dependencies implicit, which
- both results in a simpler and more flexible
- system.
+ activation which make dependencies implicit, resulting
+ in a both simpler and more flexible system.
Some unit names reflect paths existing in the
file system name space. Example: a device unit
@@ -177,18 +222,12 @@
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
+ 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 that may be
- used are %n, %N,
- %p, %P and
- %I, for the full unit name, the
- unescaped unit name, the prefix name, the unescaped
- prefix name and the unescaped instance name,
- respectively. The prefix name here refers to the
- string before the @, i.e. "getty" in the example
- above, where "tty3" is the instance name.
+ configuration options. See below for details.
If a unit file is empty (i.e. has the file size
0) or is symlinked to /dev/null
@@ -202,6 +241,154 @@
Interface
Stability Promise.
+
+
+
+
+ Unit load path
+
+ Unit files are loaded from a set of paths
+ determined during compilation, described in the two
+ tables below. Unit files found in directories higher
+ in the hierarchy override files with the same name
+ lower in the hierarchy, thus allowing overrides.
+
+
+ When systemd is running in session mode
+ () and the variable
+ $SYSTEMD_UNIT_PATH is set, this
+ contents of this variable overrides the unit load
+ path.
+
+
+
+
+ Load path when running in system mode ().
+
+
+
+
+
+
+
+ Path
+ Description
+
+
+
+
+ /run/systemd/generator.early
+ Generated units
+
+
+ &SYSTEM_CONFIG_UNIT_PATH;
+ Local configuration
+
+
+ /etc/systemd/system
+
+
+ /run/systemd/systemd
+ Volatile units
+
+
+ /run/systemd/generator
+ Generated units
+
+
+ /usr/local/lib/systemd/system
+ Units for local packages
+
+
+ &systemunitdir;
+ Systemd package configuration
+
+
+ /usr/lib/systemd/system
+ Units for installed packages
+
+
+ /lib/systemd/system
+
+
+ /run/systemd/generator.late
+ Generated units
+
+
+
+
+
+
+
+ Load path when running in session mode ().
+
+
+
+
+
+
+
+ Path
+ Description
+
+
+
+
+ /tmp/systemd-generator.early.XXXXXX
+ Generated units
+
+
+ &USER_CONFIG_UNIT_PATH;
+ Local configuration
+
+
+ /etc/systemd/user
+
+
+ /run/systemd/user
+ Volatile units
+
+
+ /tmp/systemd-generator.XXXXXX
+ Generated units
+
+
+ /usr/local/lib/systemd/user
+ Units for local packages
+
+
+ /usr/local/share/systemd/user
+
+
+ &userunitdir;
+ Systemd package configuration
+
+
+ /usr/lib/systemd/user
+ Units for installed packages
+
+
+ /usr/share/systemd/user
+
+
+ /tmp/systemd-generator.late.XXXXXX
+ Generated units
+
+
+
+
+
+ Note: the paths listed above are set at
+ compilation time and differ between distributions. The
+ "authorative" list is printed by
+ systemd at during start and daemon
+ reconfiguration.
+
+ Additional units might be loaded into systemd
+ ("linked") from directories not on the unit load
+ path. See the link command for
+ systemctl1.
+
@@ -211,22 +398,7 @@
carries generic information about the unit that is not
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=
@@ -237,6 +409,36 @@
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. The
+ URIs should be listed in order of
+ relevance, starting with the most
+ relevant. It is a good idea to first
+ reference documentation that explains
+ what the unit's purpose is, followed
+ by how it is configured, followed by
+ any other related documentation. This
+ option may be specified more than once
+ in which case the specified list of
+ URIs is merged. If the empty string is
+ assigned to this option the list is
+ reset and all prior assignments will
+ have no effect.
+
+
Requires=
@@ -274,9 +476,16 @@
Requires= in order
to achieve a system that is more
robust when dealing with failing
- services.
-
+ services.
+ Note that dependencies of this
+ type may also be configured outside of
+ the unit configuration file by
+ adding a symlink to a
+ .requires/ directory
+ accompanying the unit file. For
+ details see above.
+
RequiresOverridable=
@@ -307,7 +516,7 @@
Similar to
Requires=
- resp. RequiresOverridable=. However,
+ and RequiresOverridable=, respectively. However,
if a unit listed here is not started
already it will not be started and the
transaction fails
@@ -327,7 +536,9 @@
the transaction as a whole. This is
the recommended way to hook start-up
of one unit to the start-up of another
- unit. Note that dependencies of this
+ unit.
+
+ Note that dependencies of this
type may also be configured outside of
the unit configuration file by
adding a symlink to a
@@ -336,6 +547,38 @@
details see above.
+
+ BindsTo=
+
+ Configures requirement
+ dependencies, very similar in style to
+ Requires=, however
+ in addition to this behavior 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.
+
+
+
+ PartOf=
+
+ Configures dependencies
+ similar to Requires=,
+ but limited to stopping and restarting
+ of units. When systemd stops or restarts
+ the units listed here, the action is
+ propagated to this unit.
+ Note that this is a one way dependency -
+ changes to this unit do not affect the
+ listed units.
+
+
+
Conflicts=
@@ -421,7 +664,7 @@
Before=. If two
units have no ordering dependencies
between them they are shut down
- resp. started up simultaneously, and
+ or started up simultaneously, and
no ordering takes
place.
@@ -437,25 +680,71 @@
- RecursiveStop=
+ 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 absolute 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 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 and
- the unit stops without 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 a user request,
- units depending on it will not be
- terminated. Only if the user requested
- shutdown of a unit, all units depending
- on that unit will be shut down as well
- and at the same time. Defaults to
+ 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=
@@ -481,13 +770,13 @@
Takes a boolean
argument. If
this unit can only be activated
- (resp. deactivated) indirectly. In
+ or deactivated indirectly. In
this case explicit start-up
- (resp. termination) requested by the
+ or termination requested by the
user is denied, however if it is
- started (resp. stopped) as a
+ started or stopped as a
dependency of another unit, start-up
- (resp. termination) will succeed. This
+ or termination will succeed. This
is mostly a safety feature to ensure
that the user does not accidentally
activate units that are not intended
@@ -543,20 +832,6 @@
ones.
-
- IgnoreDependencyFailure=
-
- Takes a boolean
- argument. If and
- a requirement dependency of this unit
- fails to start up this unit will be
- started nonetheless, ignoring that
- failure. If
- (the default) and a dependency unit
- fails the unit will immediately fail
- too and the job is removed.
-
-
JobTimeoutSec=
@@ -587,45 +862,251 @@
ConditionPathExists=
+ ConditionPathExistsGlob=
+ ConditionPathIsDirectory=
+ ConditionPathIsSymbolicLink=
+ ConditionPathIsMountPoint=
+ ConditionPathIsReadWrite=
+ ConditionDirectoryNotEmpty=
+ ConditionFileNotEmpty=
+ ConditionFileIsExecutable=ConditionKernelCommandLine=
+ ConditionVirtualization=
+ ConditionSecurity=
+ ConditionCapability=
+ ConditionHost=
+ ConditionACPower=
+ ConditionNull=Before starting a unit
verify that the specified condition is
- true. With
+ true. If it is not true the starting
+ of the unit will be skipped, however
+ all ordering dependencies of it are
+ still respected. A failing condition
+ will not result in the unit being
+ moved into a failure state. The
+ condition is checked at the time the
+ queued start job is to be
+ executed.
+
+ With
ConditionPathExists=
- a file existance condition can be
+ a file existence condition is
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
+ not exist the condition will
+ fail. If the absolute path name passed
+ to
ConditionPathExists=
is prefixed with an exclamation mark
- (!), the test is negated, and the unit
- only started if the path does not
- exist. Similarly
+ ('!'), the test is negated, and the unit
+ is only started if the path does not
+ exist.
+
+ ConditionPathExistsGlob=
+ is similar to
+ ConditionPathExists=,
+ 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 readable and writable
+ (i.e. not mounted
+ read-only).
+
+ ConditionDirectoryNotEmpty=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists and is a non-empty
+ directory.
+
+ ConditionFileNotEmpty=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists and refers to a regular file
+ with a non-zero size.
+
+ ConditionFileIsExecutable=
+ is similar to
+ ConditionPathExists=
+ but verifies whether a certain path
+ exists, is a regular file and marked
+ executable.
+
+ Similar,
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, seperated
- by the equality sign). In the former
- case the kernel command line is search
- 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. If multiple conditions
- are specified the unit will be
- executed iff at least one of them
- apply (i.e. a logical OR is
- applied).
+ assignment (i.e. two words, separated
+ '='). 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 generic 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.
+
+ ConditionHost=
+ may be used to match against the
+ host name or machine ID of the
+ host. This either takes a host name
+ string (optionally with shell style
+ globs) which is tested against the
+ locally set host name as returned by
+ gethostname2,
+ or a machine ID formatted as string
+ (see
+ machine-id5).
+ The test may be negated by prepending
+ an exclamation mark.
+
+ ConditionACPower=
+ may be used to check whether the
+ system has AC power, or is exclusively
+ battery powered at the time of
+ activation of the unit. This takes a
+ boolean argument. If set to
+ true the condition
+ will hold only if at least one AC
+ connector of the system is connected
+ to a power source, or if no AC
+ connectors are known. Conversely, if
+ set to false the
+ condition will hold only if there is
+ at least one AC connector known and
+ all AC connectors are disconnected
+ from a power source.
+
+ 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. If
+ any of these options is assigned the
+ empty string the list of conditions is
+ reset completely, all previous
+ condition settings (of any kind) will
+ have no effect.
+
+
+
+ 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.
@@ -639,7 +1120,7 @@
systemctl1
tool during installation of a unit:
-
+ Alias=
@@ -653,38 +1134,17 @@
time,
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
- systemctl enable
- command. 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/
- subdirectory for a unit. This has the
+ or .requires/
+ subdirectory for a unit, respectively. This has the
effect that when the listed unit name
is activated the unit listing it is
activated
@@ -711,6 +1171,140 @@
+ The following specifiers are interpreted in the
+ Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b.
+ For their meaning see the next section.
+
+
+
+
+ Specifiers
+
+ Many settings resolve specifiers which may be
+ used to write generic unit files referring to runtime
+ or unit parameters that are replaced when the unit
+ files are loaded. The following specifiers are
+ understood:
+
+
+ Specifiers available in unit files
+
+
+
+
+
+
+ Specifier
+ Meaning
+ Details
+
+
+
+
+ %n
+ Full unit name
+
+
+
+ %N
+ Unescaped full unit name
+
+
+
+ %p
+ Prefix name
+ For instantiated units this refers to the string before the @. For non-instantiated units this refers to to the name of the unit with the type suffix removed.
+
+
+ %P
+ Unescaped prefix name
+
+
+
+ %i
+ Instance name
+ For instantiated units: 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 applicable) with / prepended (if applicable), 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.
+
+
+ %U
+ User UID
+ This is the UID 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.
+
+
+ %s
+ User shell
+ This is the shell of the configured
+ user of the unit, or (if none is set) the user
+ running the systemd instance. If the user is
+ root (UID equal to 0), the
+ shell configured in account database is
+ ignored and /bin/sh is
+ always used.
+
+
+
+ %m
+ Machine ID
+ The machine ID of the running system, formatted as string. See machine-id5 for more information.
+
+
+ %b
+ Boot ID
+ The boot ID of the running system, formatted as string. See random4 for more information.
+
+
+ %H
+ Host name
+ The host name of the running system.
+
+
+ %%
+ Escaped %
+ Single percent sign.
+
+
+
+