From c78ab91132aab9193f3c17a9a206f8825ff4be84 Mon Sep 17 00:00:00 2001 From: Zbigniew Jędrzejewski-Szmek Date: Tue, 5 Feb 2013 10:31:20 -0500 Subject: build-sys: substitute strings in systemd.unit(5) Makefile.am is updated to deal with .xml.in sources. Nothing in the output is really changed yet, this is just preparation. --- man/systemd.unit.xml | 1143 -------------------------------------------------- 1 file changed, 1143 deletions(-) delete mode 100644 man/systemd.unit.xml (limited to 'man/systemd.unit.xml') diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml deleted file mode 100644 index 7c3a6c75f8..0000000000 --- a/man/systemd.unit.xml +++ /dev/null @@ -1,1143 +0,0 @@ - - - - - - - - - systemd.unit - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.unit - 5 - - - - systemd.unit - Unit configuration - - - - systemd.service, - systemd.socket, - systemd.device, - systemd.mount, - systemd.automount, - systemd.swap, - systemd.target, - systemd.path, - systemd.timer, - systemd.snapshot - - - - Description - - 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 - supervised by - systemd1. The - syntax is inspired by XDG - Desktop Entry Specification .desktop files, which are in turn - inspired by Microsoft Windows - .ini files. - - This man page lists the common configuration - options of all the unit types. These options need to - 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 may have a - type-specific section, e.g. [Service] for a service - unit. See the respective man pages for more - information. - - Unit files may contain additional options on top - of those listed here. If systemd encounters an unknown - option it will write a warning log message but - continue loading the unit. If an option is prefixed - with it is ignored completely by - systemd. Applications may use this to include - additional information in the unit files. - - Boolean arguments used in unit files can be - written in various formats. For positive settings the - strings , , - and are - equivalent. For negative settings the strings - , , - 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. For details - see - systemd.time7. - - Empty lines and lines starting with # or ; are - 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. - - Along with a unit file - foo.service the directory - foo.service.wants/ may exist. All - 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 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). 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 sparingly and instead rely - on techniques such as bus-based or socket-based - 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 - 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. See below for details. - - 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. - - - - - Options - - Unit file may include a [Unit] section, which - carries generic information about the unit that is not - dependent on the type of unit: - - - - - Description= - A free-form string - 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. 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= - - Configures requirement - dependencies on other units. If this - 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 - be deactivated. This option may be - specified more than once, in which - case requirement dependencies for all - listed names are created. Note that - requirement dependencies do not - influence the order in which services - are started or stopped. This has to be - configured independently with the - After= or - Before= options. If - a unit - foo.service - requires a unit - bar.service as - configured with - Requires= and no - ordering is configured with - After= or - Before=, then both - units will be started simultaneously - and without any delay between them if - foo.service is - activated. Often it is a better choice - to use Wants= - instead of - Requires= in order - to achieve a system that is more - robust when dealing with failing - 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= - - Similar to - Requires=. - Dependencies listed in - RequiresOverridable= - which cannot be fulfilled or fail to - 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 - start-up of units that is not - requested by the user this dependency - must be fulfilled and otherwise the - transaction fails. Hence, this option - may be used to configure dependencies - that are normally honored unless the - user explicitly starts up the unit, in - which case whether they failed or not - is irrelevant. - - - - Requisite= - RequisiteOverridable= - - Similar to - Requires= - and RequiresOverridable=, respectively. However, - if a unit listed here is not started - already it will not be started and the - transaction fails - immediately. - - - - Wants= - - A weaker version of - Requires=. A unit - listed in this option will be started - if the configuring unit is. However, - 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 - the recommended way to hook start-up - of one unit to the start-up of another - unit. - - Note that dependencies of this - type may also be configured outside of - the unit configuration file by - adding a symlink to a - .wants/ directory - accompanying the unit file. For - 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= - - Configures negative - requirement dependencies. If a unit - has a - Conflicts= setting - 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. - - 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. - - - - Before= - After= - - Configures ordering - dependencies between units. If a unit - foo.service - contains a setting - - and both units are being started, - bar.service's - start-up is delayed until - foo.service is - started up. Note that this setting is - independent of and orthogonal to the - requirement dependencies as configured - by Requires=. It is - a common pattern to include a unit - name in both the - After= and - Requires= option in - which case the unit listed will be - started before the unit that is - configured with these options. This - option may be specified more than - once, in which case ordering - dependencies for all listed names are - created. After= is - the inverse of - Before=, i.e. while - After= ensures that - the configured unit is started after - the listed unit finished starting up, - Before= ensures the - opposite, i.e. that the configured - unit is fully started up before the - listed unit is started. Note that when - two units with an ordering dependency - between them are shut down, the - inverse of the start-up order is - applied. i.e. if a unit is configured - with After= on - another unit, the former is stopped - before the latter if both are shut - down. If one unit with an ordering - dependency on another unit is shut - down while the latter is started up, - the shut down is ordered before the - start-up regardless whether the - ordering dependency is actually of - type After= or - Before=. If two - units have no ordering dependencies - between them they are shut down - or started up simultaneously, and - no ordering takes - place. - - - - 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 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 - 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= - - Takes a boolean - 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 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 - automatically cleaned up if no other - active unit requires it. Defaults to - . - - - - RefuseManualStart= - RefuseManualStop= - - Takes a boolean - argument. If - this unit can only be activated - or deactivated indirectly. In - this case explicit start-up - or termination requested by the - user is denied, however if it is - started or stopped as a - dependency of another unit, start-up - or 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 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= - ConditionFileNotEmpty= - ConditionFileIsExecutable= - ConditionKernelCommandLine= - ConditionVirtualization= - ConditionSecurity= - ConditionCapability= - ConditionHost= - ConditionACPower= - ConditionNull= - - Before starting a unit - verify that the specified condition is - 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 existence condition is - checked before a unit is started. If - the specified absolute path name does - 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 - 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, 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. - - - - Unit file may include a [Install] section, which - carries installation information for the unit. This - section is not interpreted by - systemd1 - during runtime. It is used exclusively by the - enable and - disable commands of the - systemctl1 - tool during installation of a unit: - - - - Alias= - - Additional names this - unit shall be installed under. 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. At installation - time, - systemctl enable - will create symlinks from these names - to the unit file name. - - - - WantedBy= - RequiredBy= - - Installs a symlink in - the .wants/ - 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 - too. WantedBy=foo.service - in a service - bar.service is - mostly equivalent to - Alias=foo.service.wants/bar.service - in the same file. - - - - Also= - - Additional units to - install when this unit is - installed. If the user requests - installation of a unit with this - option configured, - systemctl enable - will automatically install units - listed in this option as - well. - - - - 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. - - - %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. - - - -
- - - - See Also - - systemd1, - systemctl8, - systemd.special7, - systemd.service5, - systemd.socket5, - systemd.device5, - systemd.mount5, - systemd.automount5, - systemd.swap5, - systemd.target5, - systemd.path5, - systemd.timer5, - systemd.snapshot5, - systemd.time7, - capabilities7, - systemd.directives7 - - - - -- cgit v1.2.3-54-g00ecf