shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2025-01-18 06:03:42 +03:00
Code

Merge pull request #2578 from keszybz/man-pages

Browse Source 
man: follow up fixes for #2575
This commit is contained in:
Daniel Mack 2016-02-11 10:22:05 +01:00
commit 53359675fc
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> <refsect2>
<title>Parameter Syntax</title> <title>Parameter Syntax</title>
<para>Unit commands listed above take either a single unit name <para>Unit commands listed above take either a single unit name (designated as <replaceable>NAME</replaceable>),
(designated as <replaceable>NAME</replaceable>), or multiple or multiple unit specifications (designated as <replaceable>PATTERN</replaceable>...). In the first case, the
unit specifications (designated as unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"),
<replaceable>PATTERN</replaceable>...). In the first case, the systemctl will append a suitable suffix, <literal>.service</literal> by default, and a type-specific suffix in
unit name with or without a suffix must be given. If the suffix case of commands which operate only on specific unit types. For example,
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,
<programlisting># systemctl start sshd</programlisting> and <programlisting># systemctl start sshd</programlisting> and
<programlisting># systemctl start sshd.service</programlisting> <programlisting># systemctl start sshd.service</programlisting>
are equivalent, as are are equivalent, as are
<programlisting># systemctl isolate default</programlisting> <programlisting># systemctl isolate default</programlisting>
and and
<programlisting># systemctl isolate default.target</programlisting> <programlisting># systemctl isolate default.target</programlisting>
Note that (absolute) paths to device nodes are automatically Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute)
converted to device unit names, and other (absolute) paths to paths to mount unit names.
mount unit names.
<programlisting># systemctl status /dev/sda <programlisting># systemctl status /dev/sda
# systemctl status /home</programlisting> # systemctl status /home</programlisting>
are equivalent to: 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 <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 <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 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 their unit files. Make sure that the file that is included has the appropriate a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for
section headers before any directive. Note that for instanced units, this logic will first look for the instance instantiated units, this logic will first look for the instance <literal>.d/</literal> subdirectory and read its
<literal>.d/</literal> subdirectory and read its <literal>.conf</literal> files, followed by the template <literal>.conf</literal> files, followed by the template <literal>.d/</literal> subdirectory and the
<literal>.d/</literal> subdirectory and reads its <literal>.conf</literal> files. Also note that settings from the <literal>.conf</literal> files there. Also note that settings from the <literal>[Install]</literal> section are not
<literal>[Install]</literal> section are not available in drop-in unit files, and have no effect.</para> honoured in drop-in unit files, and have no effect.</para>
<para>In addition to <filename>/etc/systemd/system</filename>, <para>In addition to <filename>/etc/systemd/system</filename>,
the drop-in <literal>.conf</literal> files for system services the drop-in <literal>.conf</literal> files for system services
@ -1067,9 +1067,9 @@
<listitem><para>Similar to the <varname>ConditionArchitecture=</varname>, <listitem><para>Similar to the <varname>ConditionArchitecture=</varname>,
<varname>ConditionVirtualization=</varname>, …, condition settings described above, these settings add <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 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 that is not met results in failure of the start job (which means this is logged loudly). Use assertion
loudly). Use assertion expressions for units that cannot operate when specific requirements are not met, and expressions for units that cannot operate when specific requirements are not met, and when this is something
where this is something the administrator or user should look into.</para></listitem> the administrator or user should look into.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>