man: follow up fixes for #2575

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>