shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00
Code

man: follow up fixes for #2575

Browse Source
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2016-02-10 19:49:40 -05:00
parent a858cd7113
commit da25e02913
2 changed files with 16 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
man/systemctl.xml
View File

@ -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:

18
man/systemd.unit.xml
View File

@ -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>