diff options
| -rw-r--r-- | man/systemctl.xml | 19 | ||||
| -rw-r--r-- | man/systemd.unit.xml | 18 |
2 files changed, 16 insertions, 21 deletions
diff --git a/man/systemctl.xml b/man/systemctl.xml index 50eb939313..1480bf8380 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1698,24 +1698,19 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service <refsect2> <title>Parameter Syntax</title> - <para>Unit commands listed above take either a single unit name - (designated as <replaceable>NAME</replaceable>), or multiple - unit specifications (designated as - <replaceable>PATTERN</replaceable>...). In the first case, the - unit name with or without a suffix must be given. If the suffix - is not specified ("abbreviated"), systemctl will append a suitable suffix, - <literal>.service</literal> by default, and a type-specific - suffix in case of commands which operate only on specific unit - types. For example, + <para>Unit commands listed above take either a single unit name (designated as <replaceable>NAME</replaceable>), + or multiple unit specifications (designated as <replaceable>PATTERN</replaceable>...). In the first case, the + unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"), + systemctl will append a suitable suffix, <literal>.service</literal> by default, and a type-specific suffix in + case of commands which operate only on specific unit types. For example, <programlisting># systemctl start sshd</programlisting> and <programlisting># systemctl start sshd.service</programlisting> are equivalent, as are <programlisting># systemctl isolate default</programlisting> and <programlisting># systemctl isolate default.target</programlisting> - Note that (absolute) paths to device nodes are automatically - converted to device unit names, and other (absolute) paths to - mount unit names. + Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute) + paths to mount unit names. <programlisting># systemctl status /dev/sda # systemctl status /home</programlisting> are equivalent to: diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 16aded89d1..5794681963 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -180,12 +180,12 @@ <para>Along with a unit file <filename>foo.service</filename>, a "drop-in" directory <filename>foo.service.d/</filename> may exist. All files with the suffix <literal>.conf</literal> 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 - <literal>.d/</literal> subdirectory and read its <literal>.conf</literal> files, followed by the template - <literal>.d/</literal> subdirectory and reads its <literal>.conf</literal> files. Also note that settings from the - <literal>[Install]</literal> section are not available in drop-in unit files, and have no effect.</para> + directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings for + a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for + instantiated units, this logic will first look for the instance <literal>.d/</literal> subdirectory and read its + <literal>.conf</literal> files, followed by the template <literal>.d/</literal> subdirectory and the + <literal>.conf</literal> files there. Also note that settings from the <literal>[Install]</literal> section are not + honoured in drop-in unit files, and have no effect.</para> <para>In addition to <filename>/etc/systemd/system</filename>, the drop-in <literal>.conf</literal> files for system services @@ -1067,9 +1067,9 @@ <listitem><para>Similar to the <varname>ConditionArchitecture=</varname>, <varname>ConditionVirtualization=</varname>, …, 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.</para></listitem> + that is not met results in failure of the start job (which means this is logged loudly). Use assertion + expressions for units that cannot operate when specific requirements are not met, and when this is something + the administrator or user should look into.</para></listitem> </varlistentry> <varlistentry> |