From 41448597f2289c570e96315abf34adab4ff204e1 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Wed, 10 Feb 2016 21:30:25 +0100 Subject: man: document distinction between ConditionXYZ= and AssertXYZ= References: #2468 --- man/systemd.unit.xml | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) (limited to 'man/systemd.unit.xml') diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 46b288f20b..04c4515cd9 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -827,13 +827,14 @@ useful and probably just confusing. --> - 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. + Before starting a unit, verify that the specified condition is true. If it is not true, the + starting of the unit will be (mostly silently) 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. Use condition expressions in order to silently skip + units that do not apply to the local running system, for example because the kernel or runtime environment + doesn't require its functionality. Use the various AssertArchitecture=, + AssertVirtualization=, … options for a similar mechanism that puts the unit in a failure + state and logs about the failed check (see below). ConditionArchitecture= may be used to check whether the system is running on a specific @@ -1067,14 +1068,12 @@ AssertFileNotEmpty= AssertFileIsExecutable= - Similar to the - ConditionArchitecture=, - ConditionVirtualization=, etc., condition - settings described above, these settings add assertion checks - to the start-up of the unit. However, unlike the conditions - settings, any assertion setting that is not met results in - failure of the start job it was triggered - by. + Similar to the ConditionArchitecture=, + ConditionVirtualization=, …, condition settings described above, these settings add + assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting + that is not met results in failure of the start job it was triggered by (which means this is logged about + loudly). Use assertion expressions for units that cannot operate when specific requirements are not met, and + where this is something the administrator or user should look into. -- cgit v1.2.3-54-g00ecf From be73bb486a1a1bb43a04319c3cb0b639edd6b98f Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Wed, 10 Feb 2016 21:39:36 +0100 Subject: man: document that [Install] has no effect in unit file .d/*.conf drop-ins Fixes: #1774 Fixes: #1090 --- man/systemd.unit.xml | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) (limited to 'man/systemd.unit.xml') diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 04c4515cd9..16aded89d1 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -178,18 +178,14 @@ 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. Note that, for - instanced units, this logic will first look for the instance - .d/ subdirectory and read its - .conf files, followed by the template - .d/ subdirectory and reads its - .conf files. + Along with a unit file foo.service, a "drop-in" 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. Note that for instanced units, this logic will first look for the instance + .d/ subdirectory and read its .conf files, followed by the template + .d/ subdirectory and reads its .conf files. Also note that settings from the + [Install] section are not available in drop-in unit files, and have no effect. In addition to /etc/systemd/system, the drop-in .conf files for system services @@ -1093,15 +1089,13 @@ [Install] Section Options - Unit file may include an [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: + Unit files may include an [Install] section, which carries installation information for + the unit. This section is not interpreted by + systemd1 during runtime; it is + used by the enable and disable commands of the + systemctl1 tool during + installation of a unit. Note that settings in the [Install] section may not appear in + .d/*.conf unit file drop-ins (see above). -- cgit v1.2.3-54-g00ecf