</varlistentry>
<varlistentry>
- <term><command>is-failed <replaceable>PATTERN</replaceable>…</command></term>
+ <term><command>is-failed <optional><replaceable>PATTERN</replaceable>…</optional></command></term>
<listitem>
- <para>Check whether any of the specified units are in a
- "failed" state. Returns an exit code
- <constant>0</constant> if at least one has failed,
- non-zero otherwise. Unless <option>--quiet</option> is
- specified, this will also print the current unit state to
- standard output.</para>
+ <para>Check whether any of the specified units is in the "failed" state. If no unit is specified,
+ check whether there are any failed units, which corresponds to the <literal>degraded</literal> state
+ returned by <command>is-system-running</command>. Returns an exit code <constant>0</constant>
+ if at least one has failed, non-zero otherwise. Unless <option>--quiet</option> is specified, this
+ will also print the current unit or system state to standard output.</para>
<xi:include href="version-info.xml" xpointer="v197"/>
</listitem>
It will <emphasis>not</emphasis> fail if any of the commands configured to stop the unit
(<varname>ExecStop=</varname>, etc.) fail, because the manager will still forcibly terminate the
unit.</para>
+
+ <para>If a unit that gets stopped can still be triggered by other units, a warning containing
+ the names of the triggering units is shown. <option>--no-warn</option> can be used to suppress
+ the warning.</para>
</listitem>
</varlistentry>
<varlistentry>
<!-- Note that we don't document force-reload here, as that is just compatibility support, and we generally
don't document that. -->
- <xi:include href="version-info.xml" xpointer="v229"/>
+ <xi:include href="version-info.xml" xpointer="v229"/>
</listitem>
</varlistentry>
<varlistentry>
<option>ExecReload=</option>, <option>ExecStartPre=</option>, etc.) run in distinct namespaces.
</para>
+ <para>If supported by the kernel, any prior mount on the selected target will be replaced by the
+ new mount. If not supported, any prior mount will be over-mounted, but remain pinned and
+ inaccessible.</para>
+
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<option>ExecReload=</option>, <option>ExecStartPre=</option>, etc.) run in distinct namespaces.
</para>
+ <para>If supported by the kernel, any prior mount on the selected target will be replaced by the
+ new mount. If not supported, any prior mount will be over-mounted, but remain pinned and
+ inaccessible.</para>
+
<para>Example:
<programlisting>systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid</programlisting>
<programlisting>systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img</programlisting>
executed. This output may be suppressed by passing <option>--quiet</option>.
</para>
+ <para>If a unit gets disabled but its triggering units are still active, a warning containing
+ the names of the triggering units is shown. <option>--no-warn</option> can be used to suppress
+ the warning.</para>
+
<para>When this command is used with <option>--user</option>, the units being operated on might
still be enabled in global scope, and thus get started automatically even after a successful
disablement in user scope. In this case, a warning about it is shown, which can be suppressed
</tgroup>
</table>
- <xi:include href="version-info.xml" xpointer="v238"/>
-
+ <xi:include href="version-info.xml" xpointer="v238"/>
</listitem>
</varlistentry>
<option>--user</option> mode, in which case the directories are below the user's home directory
however.</para>
+ <para>If a unit gets masked but its triggering units are still active, a warning containing
+ the names of the triggering units is shown. <option>--no-warn</option> can be used to suppress
+ the warning.</para>
+
<xi:include href="version-info.xml" xpointer="v238"/>
</listitem>
</varlistentry>
<command>enable</command>.</para>
<xi:include href="version-info.xml" xpointer="v217"/>
-
</listitem>
</varlistentry>
<term><command>edit <replaceable>UNIT</replaceable>…</command></term>
<listitem>
- <para>Edit a drop-in snippet or a whole replacement file if
- <option>--full</option> is specified, to extend or override the
- specified unit.</para>
+ <para>Edit or replace a drop-in snippet or the main unit file, to extend or override the
+ definition of the specified unit.</para>
+
+ <para>Depending on whether <option>--system</option> (the default), <option>--user</option>, or
+ <option>--global</option> is specified, this command will operate on the system unit files, unit
+ files for the calling user, or the unit files shared between all users.</para>
+
+ <para>The editor (see the "Environment" section below) is invoked on temporary files which will
+ be written to the real location if the editor exits successfully. After the editing is finished,
+ configuration is reloaded, equivalent to <command>systemctl daemon-reload --system</command> or
+ <command>systemctl daemon-reload --user</command>. For <command>edit --global</command>, the
+ reload is not performed and the edits will take effect only for subsequent logins (or after a
+ reload is requested in a different way).</para>
- <para>Depending on whether <option>--system</option> (the default),
- <option>--user</option>, or <option>--global</option> is specified,
- this command creates a drop-in file for each unit either for the system,
- for the calling user, or for all futures logins of all users. Then,
- the editor (see the "Environment" section below) is invoked on
- temporary files which will be written to the real location if the
- editor exits successfully.</para>
+ <para>If <option>--full</option> is specified, a replacement for the main unit file will be
+ created or edited. Otherwise, a drop-in file will be created or edited.</para>
<para>If <option>--drop-in=</option> is specified, the given drop-in file name
will be used instead of the default <filename>override.conf</filename>.</para>
- <para>If <option>--full</option> is specified, this will copy the
- original units instead of creating drop-in files.</para>
-
- <para>If <option>--force</option> is specified and any units do
- not already exist, new unit files will be opened for editing.</para>
+ <para>The unit must exist, i.e. its main unit file must be present. If <option>--force</option>
+ is specified, this requirement is ignored and a new unit may be created (with
+ <option>--full</option>), or a drop-in for a nonexistent unit may be created.</para>
<para>If <option>--runtime</option> is specified, the changes will
be made temporarily in <filename>/run/</filename> and they will be
lost on the next reboot.</para>
+ <para>If <option>--stdin</option> is specified, the new contents will be read from standard
+ input. In this mode, the old contents of the file are discarded.</para>
+
<para>If the temporary file is empty upon exit, the modification of
the related unit is canceled.</para>
- <para>After the units have been edited, systemd configuration is
- reloaded (in a way that is equivalent to <command>daemon-reload</command>).
- </para>
-
<para>Note that this command cannot be used to remotely edit units
and that you cannot temporarily edit units which are in
<filename>/etc/</filename>, since they take precedence over
</tgroup>
</table>
- <xi:include href="version-info.xml" xpointer="v215"/>
+ <xi:include href="version-info.xml" xpointer="v215"/>
</listitem>
</varlistentry>
<para>This command honors <option>--force</option> and <option>--when=</option> in a similar way
as <command>halt</command>.</para>
+ <para>If a new kernel has been loaded via <command>kexec --load</command>, a
+ <command>kexec</command> will be performed instead of a reboot, unless
+ <literal>SYSTEMCTL_SKIP_AUTO_KEXEC=1</literal> has been set. If a new root file system has
+ been set up on <literal>/run/nextroot/</literal>, a <command>soft-reboot</command> will be
+ performed instead of a reboot, unless <literal>SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1</literal> has
+ been set.</para>
+
<xi:include href="version-info.xml" xpointer="v246"/>
</listitem>
</varlistentry>
<para>This command honors <option>--force</option> and <option>--when=</option> similarly
to <command>halt</command>.</para>
+
+ <para>If a new kernel has been loaded via <command>kexec --load</command>, a
+ <command>kexec</command> will be performed when <command>reboot</command> is invoked, unless
+ <literal>SYSTEMCTL_SKIP_AUTO_KEXEC=1</literal> has been set.</para>
</listitem>
</varlistentry>
<citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for details.</para>
+ <para>If a new root file system has been set up on <literal>/run/nextroot/</literal>, a
+ <command>soft-reboot</command> will be performed when <command>reboot</command> is invoked,
+ unless <literal>SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1</literal> has been set.</para>
+
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><command>sleep</command></term>
+
+ <listitem>
+ <para>Put the system to sleep, through <command>suspend</command>, <command>hibernate</command>,
+ <command>hybrid-sleep</command>, or <command>suspend-then-hibernate</command>. The sleep operation
+ to use is automatically selected by <citerefentry>
+ <refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ By default, <command>suspend-then-hibernate</command> is used, and falls back to <command>suspend</command>
+ and then <command>hibernate</command> if not supported. Refer to <varname>SleepOperation=</varname>
+ setting in <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for more details. This command is asynchronous, and will return after the sleep operation is
+ successfully enqueued. It will not wait for the sleep/resume cycle to complete.</para>
+
+ <xi:include href="version-info.xml" xpointer="v256"/>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><command>suspend</command></term>
for more details. The patterns are matched against the primary names of
units currently in memory, and patterns which do not match anything
are silently skipped. For example:
- <programlisting># systemctl stop sshd@*.service</programlisting>
+ <programlisting># systemctl stop "sshd@*.service"</programlisting>
will stop all <filename>sshd@.service</filename> instances. Note that alias names of units, and units that aren't
in memory are not considered for glob expansion.
</para>
<option>-P</option> once will also affect all properties listed with
<option>-p</option>/<option>--property=</option>.</para>
- <xi:include href="version-info.xml" xpointer="v246"/>
+ <xi:include href="version-info.xml" xpointer="v246"/>
</listitem>
</varlistentry>
<para>When printing properties with <command>show</command>, only print the value, and skip the
property name and <literal>=</literal>. Also see option <option>-P</option> above.</para>
- <xi:include href="version-info.xml" xpointer="v230"/>
+ <xi:include href="version-info.xml" xpointer="v230"/>
</listitem>
</varlistentry>
<listitem>
<para>When showing sockets, show the type of the socket.</para>
- <xi:include href="version-info.xml" xpointer="v202"/>
+ <xi:include href="version-info.xml" xpointer="v202"/>
</listitem>
</varlistentry>
<term><option>--job-mode=</option></term>
<listitem>
- <para>When queuing a new job, this option controls how to deal with
- already queued jobs. It takes one of <literal>fail</literal>,
- <literal>replace</literal>,
- <literal>replace-irreversibly</literal>,
- <literal>isolate</literal>,
- <literal>ignore-dependencies</literal>,
- <literal>ignore-requirements</literal>,
- <literal>flush</literal>,
- <literal>triggering</literal>, or
- <literal>restart-dependencies</literal>. Defaults to
- <literal>replace</literal>, except when the
- <command>isolate</command> command is used which implies the
- <literal>isolate</literal> job mode.</para>
-
- <para>If <literal>fail</literal> is specified and a requested
- operation conflicts with a pending job (more specifically:
- causes an already pending start job to be reversed into a stop
- job or vice versa), cause the operation to fail.</para>
-
- <para>If <literal>replace</literal> (the default) is
- specified, any conflicting pending job will be replaced, as
- necessary.</para>
-
- <para>If <literal>replace-irreversibly</literal> is specified,
- operate like <literal>replace</literal>, but also mark the new
- jobs as irreversible. This prevents future conflicting
- transactions from replacing these jobs (or even being enqueued
- while the irreversible jobs are still pending). Irreversible
- jobs can still be cancelled using the <command>cancel</command>
- command. This job mode should be used on any transaction which
- pulls in <filename>shutdown.target</filename>.</para>
-
- <para><literal>isolate</literal> is only valid for start
- operations and causes all other units to be stopped when the
- specified unit is started. This mode is always used when the
- <command>isolate</command> command is used.</para>
-
- <para><literal>flush</literal> will cause all queued jobs to
- be canceled when the new job is enqueued.</para>
-
- <para>If <literal>ignore-dependencies</literal> is specified,
- then all unit dependencies are ignored for this new job and
- the operation is executed immediately. If passed, no required
- units of the unit passed will be pulled in, and no ordering
- dependencies will be honored. This is mostly a debugging and
- rescue tool for the administrator and should not be used by
- applications.</para>
-
- <para><literal>ignore-requirements</literal> is similar to
- <literal>ignore-dependencies</literal>, but only causes the
- requirement dependencies to be ignored, the ordering
- dependencies will still be honored.</para>
-
- <para><literal>triggering</literal> may only be used with
- <command>systemctl stop</command>. In this mode, the specified
- unit and any active units that trigger it are stopped. See the
- discussion of
- <varname>Triggers=</varname> in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for more information about triggering units.</para>
-
- <para><literal>restart-dependencies</literal> may only be used with
- <command>systemctl start</command>. In this mode, dependencies of
- the specified unit will receive restart propagation, as if a restart
- job had been enqueued for the unit.</para>
-
- <xi:include href="version-info.xml" xpointer="v209"/>
+
<para>When queuing a new job, this option controls how to deal with
+ already queued jobs. It takes one of <literal>fail</literal>,
+ <literal>replace</literal>,
+ <literal>replace-irreversibly</literal>,
+ <literal>isolate</literal>,
+ <literal>ignore-dependencies</literal>,
+ <literal>ignore-requirements</literal>,
+ <literal>flush</literal>,
+ <literal>triggering</literal>, or
+ <literal>restart-dependencies</literal>. Defaults to
+ <literal>replace</literal>, except when the
+ <command>isolate</command> command is used which implies the
+ <literal>isolate</literal> job mode.</para>
+
+
<para>If <literal>fail</literal> is specified and a requested
+ operation conflicts with a pending job (more specifically:
+ causes an already pending start job to be reversed into a stop
+ job or vice versa), cause the operation to fail.</para>
+
+
<para>If <literal>replace</literal> (the default) is
+ specified, any conflicting pending job will be replaced, as
+ necessary.</para>
+
+
<para>If <literal>replace-irreversibly</literal> is specified,
+ operate like <literal>replace</literal>, but also mark the new
+ jobs as irreversible. This prevents future conflicting
+ transactions from replacing these jobs (or even being enqueued
+ while the irreversible jobs are still pending). Irreversible
+ jobs can still be cancelled using the <command>cancel</command>
+ command. This job mode should be used on any transaction which
+ pulls in <filename>shutdown.target</filename>.</para>
+
+
<para><literal>isolate</literal> is only valid for start
+ operations and causes all other units to be stopped when the
+ specified unit is started. This mode is always used when the
+ <command>isolate</command> command is used.</para>
+
+
<para><literal>flush</literal> will cause all queued jobs to
+ be canceled when the new job is enqueued.</para>
+
+
<para>If <literal>ignore-dependencies</literal> is specified,
+ then all unit dependencies are ignored for this new job and
+ the operation is executed immediately. If passed, no required
+ units of the unit passed will be pulled in, and no ordering
+ dependencies will be honored. This is mostly a debugging and
+ rescue tool for the administrator and should not be used by
+ applications.</para>
+
+
<para><literal>ignore-requirements</literal> is similar to
+ <literal>ignore-dependencies</literal>, but only causes the
+ requirement dependencies to be ignored, the ordering
+ dependencies will still be honored.</para>
+
+
<para><literal>triggering</literal> may only be used with
+ <command>systemctl stop</command>. In this mode, the specified
+ unit and any active units that trigger it are stopped. See the
+ discussion of
+ <varname>Triggers=</varname> in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for more information about triggering units.</para>
+
+
<para><literal>restart-dependencies</literal> may only be used with
+ <command>systemctl start</command>. In this mode, dependencies of
+ the specified unit will receive restart propagation, as if a restart
+ job had been enqueued for the unit.</para>
+
+ <xi:include href="version-info.xml" xpointer="v209"/>
</listitem>
</varlistentry>
run as effect of the enqueued jobs might request further jobs to be pulled in. This means that
completion of the listed jobs might ultimately entail more jobs than the listed ones.</para>
- <xi:include href="version-info.xml" xpointer="v242"/>
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
<listitem>
<para>Shortcut for <option>--check-inhibitors=no</option>.</para>
- <xi:include href="version-info.xml" xpointer="v198"/>
+ <xi:include href="version-info.xml" xpointer="v198"/>
</listitem>
</varlistentry>
</listitem>
<listitem>
<para>when using <command>disable</command> combined with <option>--user</option> on units
- that are enabled in global scope.</para>
+ that are enabled in global scope,</para>
+ </listitem>
+ <listitem>
+ <para>when a <command>stop</command>-ped, <command>disable</command>-d, or <command>mask</command>-ed
+ unit still has active triggering units.</para>
</listitem>
</itemizedlist>
</para>
<filename>&UMOUNT_PATH;</filename>), but no main process is defined. If omitted, defaults to
<option>all</option>.</para>
- <xi:include href="version-info.xml" xpointer="v252"/>
+ <xi:include href="version-info.xml" xpointer="v252"/>
</listitem>
</varlistentry>
<varname>FileDescriptorStorePreserve=</varname> option is enabled, since the file descriptor store
is otherwise cleaned automatically when the unit is stopped.</para>
- <xi:include href="version-info.xml" xpointer="v243"/>
+ <xi:include href="version-info.xml" xpointer="v243"/>
</listitem>
</varlistentry>
short message explaining the reason for the operation. The message will be logged together with the default
shutdown message.</para>
- <xi:include href="version-info.xml" xpointer="v225"/>
+ <xi:include href="version-info.xml" xpointer="v225"/>
</listitem>
</varlistentry>
or stop operation is only carried out when the respective enable or
disable operation has been successful.</para>
- <xi:include href="version-info.xml" xpointer="v220"/>
+ <xi:include href="version-info.xml" xpointer="v220"/>
</listitem>
</varlistentry>
enabled according to the preset rules, or only enabled, or
only disabled.</para>
- <xi:include href="version-info.xml" xpointer="v215"/>
+ <xi:include href="version-info.xml" xpointer="v215"/>
</listitem>
</varlistentry>
<term><option>--firmware-setup</option></term>
<listitem>
- <para>When used with the <command>reboot</command> command, indicate to the system's firmware to
- reboot into the firmware setup interface. Note that this functionality is not available on all
- systems.</para>
+ <para>When used with the <command>reboot</command>, <command>poweroff</command>, or
+ <command>halt</command> command, indicate to the system's firmware to reboot into the firmware
+ setup interface for the next boot. Note that this functionality is not available on all systems.
+ </para>
- <xi:include href="version-info.xml" xpointer="v220"/>
+ <xi:include href="version-info.xml" xpointer="v220"/>
</listitem>
</varlistentry>
<term><option>--boot-loader-menu=<replaceable>timeout</replaceable></option></term>
<listitem>
- <para>When used with the <command>reboot</command> command, indicate to the system's boot loader to
- show the boot loader menu on the following boot. Takes a time value as parameter — indicating the
- menu timeout. Pass zero in order to disable the menu timeout. Note that not all boot loaders
- support this functionality.</para>
+ <para>When used with the <command>reboot</command>, <command>poweroff</command>, or
+ <command>halt</command> command, indicate to the system's boot loader to show the boot loader menu
+ on the following boot. Takes a time value as parameter — indicating the menu timeout. Pass zero
+ in order to disable the menu timeout. Note that not all boot loaders support this functionality.
+ </para>
- <xi:include href="version-info.xml" xpointer="v242"/>
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
<term><option>--boot-loader-entry=<replaceable>ID</replaceable></option></term>
<listitem>
- <para>When used with the <command>reboot</command> command, indicate to the system's boot loader to
- boot into a specific boot loader entry on the following boot. Takes a boot loader entry identifier
- as argument, or <literal>help</literal> in order to list available entries. Note that not all boot
- loaders support this functionality.</para>
+ <para>When used with the <command>reboot</command>, <command>poweroff</command>, or
+ <command>halt</command> command, indicate to the system's boot loader to boot into a specific
+ boot loader entry on the following boot. Takes a boot loader entry identifier as argument,
+ or <literal>help</literal> in order to list available entries. Note that not all boot loaders
+ support this functionality.</para>
- <xi:include href="version-info.xml" xpointer="v242"/>
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
<term><option>--reboot-argument=</option></term>
<listitem>
- <para>This switch is used with <command>reboot</command>. The value is architecture and firmware specific. As an example, <literal>recovery</literal>
- might be used to trigger system recovery, and <literal>fota</literal> might be used to trigger a
- <quote>firmware over the air</quote> update.</para>
+ <para>This switch is used with <command>reboot</command>. The value is architecture and firmware
+ specific. As an example, <literal>recovery</literal> might be used to trigger system recovery, and
+ <literal>fota</literal> might be used to trigger a <quote>firmware over the air</quote>
+ update.</para>
- <xi:include href="version-info.xml" xpointer="v246"/>
+ <xi:include href="version-info.xml" xpointer="v246"/>
</listitem>
</varlistentry>
the output is printed as a list instead of a tree, and the bullet
circles are omitted.</para>
- <xi:include href="version-info.xml" xpointer="v203"/>
+ <xi:include href="version-info.xml" xpointer="v203"/>
</listitem>
</varlistentry>
</varlistentry>
</variablelist>
- <xi:include href="version-info.xml" xpointer="v247"/>
+ <xi:include href="version-info.xml" xpointer="v247"/>
</listitem>
</varlistentry>
<listitem><para>When used with <command>bind</command>, creates a read-only bind mount.</para>
- <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+ <xi:include href="version-info.xml" xpointer="v248"/>
+ </listitem>
</varlistentry>
<varlistentry>
- <term><option>--drop-in=</option></term>
+ <term><option>--drop-in=</option><replaceable>NAME</replaceable></term>
- <listitem>
- <para>When used with <command>edit</command>, use the given drop-in file name instead of
- <filename>override.conf</filename>.</para>
+ <listitem><para>When used with <command>edit</command>, use <replaceable>NAME</replaceable> as the
+ drop-in file name instead of <filename>override.conf</filename>.</para>
<xi:include href="version-info.xml" xpointer="v253"/>
</listitem>
section "PARSING TIMESTAMPS". Specially, if <literal>show</literal> is given, the currently scheduled
action will be shown, which can be canceled by passing an empty string or <literal>cancel</literal>.</para>
- <xi:include href="version-info.xml" xpointer="v254"/>
+ <xi:include href="version-info.xml" xpointer="v254"/>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>--stdin</option></term>
+
+ <listitem>
+ <para>When used with <command>edit</command>, the contents of the file will be read from standard
+ input and the editor will not be launched. In this mode, the old contents of the file are
+ completely replaced. This is useful to "edit" unit files from scripts:</para>
+
+ <programlisting>$ systemctl edit --drop-in=limits.conf --stdin some-service.service <<EOF
+[Unit]
+AllowedCPUs=7,11
+EOF
+ </programlisting>
+
+ <para>Multiple drop-ins may be "edited" in this mode; the same contents will be written to all of
+ them.</para>
+
+ <xi:include href="version-info.xml" xpointer="v256"/>
</listitem>
</varlistentry>
<refsect1>
<title>See Also</title>
- <para>
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
- <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
- <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- </para>
+ <para><simplelist type="inline">
+ <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
+ <member><citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
+ <member><citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
+ </simplelist></para>
</refsect1>
</refentry>
projects / thirdparty / systemd.git / blobdiff