summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--man/systemctl.xml19
-rw-r--r--man/systemd.unit.xml18
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>