-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % entities SYSTEM "custom-entities.ent" >
<!--
SPDX-License-Identifier: LGPL-2.1+
-
- This file is part of systemd.
-
- Copyright 2010 Lennart Poettering
-->
<refentry id="systemctl"
<refentryinfo>
<title>systemctl</title>
<productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
<term><option>--ignore-inhibitors</option></term>
<listitem>
- <para>When system shutdown or a sleep state is requested,
- ignore inhibitor locks. Applications can establish inhibitor
- locks to avoid that certain important operations (such as CD
- burning or suchlike) are interrupted by system shutdown or a
- sleep state. Any user may take these locks and privileged
- users may override these locks. If any locks are taken,
- shutdown and sleep state requests will normally fail
- (regardless of whether privileged or not) and a list of active locks
- is printed. However, if <option>--ignore-inhibitors</option>
- is specified, the locks are ignored and not printed, and the
- operation attempted anyway, possibly requiring additional
- privileges.</para>
+ <para>When system shutdown or a sleep state is requested, ignore inhibitor locks. Applications can establish
+ inhibitor locks to avoid that certain important operations (such as CD burning or suchlike) are interrupted
+ by system shutdown or a sleep state. Any user may take these locks and privileged users may override these
+ locks. If any locks are taken, shutdown and sleep state requests will normally fail (unless privileged) and a
+ list of active locks is printed. However, if <option>--ignore-inhibitors</option> is specified, the
+ established locks are ignored and not shown, and the operation attempted anyway, possibly requiring
+ additional privileges.</para>
</listitem>
</varlistentry>
<variablelist>
<varlistentry>
- <term><command>list-units <optional><replaceable>PATTERN</replaceable>…</optional></command></term>
+ <term><command>list-units</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
<listitem>
<para>List units that <command>systemd</command> currently has in memory. This includes units that are
boot-efi.mount loaded active mounted /boot/efi
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
-● user@1000.service loaded active running User Manager for UID 1000
-…
+● user@1000.service loaded failed failed User Manager for UID 1000
+ …
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
LOAD = Reflects whether the unit definition was properly loaded.
terminal supports that. A colored dot is shown next to services which
were masked, not found, or otherwise failed.</para>
- <para>The LOAD column shows the load state, one of
- <constant>loaded</constant>, <constant>not-found</constant>,
- <constant>stub</constant>, <constant>error</constant>,
- <constant>merged</constant>, <constant>masked</constant>. The ACTIVE
- columns shows the general unit state, one of <constant>active</constant>,
- <constant>reloading</constant>, <constant>inactive</constant>,
- <constant>failed</constant>, <constant>activating</constant>,
- <constant>deactivating</constant>. The SUB column shows the
- unit-type-specific detailed state of the unit, possible values vary by
- unit type. The list of possible LOAD, ACTIVE, and SUB states is not
- constant and new systemd releases may both add and remove values.
- <programlisting>systemctl --state=help</programlisting> command maybe be
- used to display the current set of possible values.</para>
+ <para>The LOAD column shows the load state, one of <constant>loaded</constant>,
+ <constant>not-found</constant>, <constant>bad-setting</constant>, <constant>error</constant>,
+ <constant>masked</constant>. The ACTIVE columns shows the general unit state, one of
+ <constant>active</constant>, <constant>reloading</constant>, <constant>inactive</constant>,
+ <constant>failed</constant>, <constant>activating</constant>, <constant>deactivating</constant>. The SUB
+ column shows the unit-type-specific detailed state of the unit, possible values vary by unit type. The list
+ of possible LOAD, ACTIVE, and SUB states is not constant and new systemd releases may both add and remove
+ values. <programlisting>systemctl --state=help</programlisting> command maybe be used to display the
+ current set of possible values.</para>
<para>This is the default command.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><command>list-sockets <optional><replaceable>PATTERN</replaceable>…</optional></command></term>
+ <term><command>list-sockets</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
<listitem>
<para>List socket units currently in memory, ordered by listening address. If one or more
</varlistentry>
<varlistentry>
- <term><command>list-timers <optional><replaceable>PATTERN</replaceable>…</optional></command></term>
+ <term><command>list-timers</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
<listitem>
<para>List timer units currently in memory, ordered by the time they elapse next. If one or more
<para>The "Loaded:" line in the output will show <literal>loaded</literal> if the unit has been loaded into
memory. Other possible values for "Loaded:" include: <literal>error</literal> if there was a problem
- loading it, <literal>not-found</literal>, and <literal>masked</literal>. Along with showing the path to
- the unit file, this line will also show the enablement state. Enabled commands start at boot. See the
- full table of possible enablement states — including the definition of <literal>masked</literal> — in the
- documentation for the <command>is-enabled</command> command.
+ loading it, <literal>not-found</literal> if not unit file was found for this unit,
+ <literal>bad-setting</literal> if an essential unit file setting could not be parsed and
+ <literal>masked</literal> if the unit file has been masked. Along with showing the path to the unit file,
+ this line will also show the enablement state. Enabled commands start at boot. See the full table of
+ possible enablement states — including the definition of <literal>masked</literal> — in the documentation
+ for the <command>is-enabled</command> command.
</para>
<para>The "Active:" line shows active state. The value is usually <literal>active</literal> or
<variablelist>
<varlistentry>
- <term><command>list-unit-files <optional><replaceable>PATTERN…</replaceable></optional></command></term>
+ <term><command>list-unit-files</command> <optional><replaceable>PATTERN…</replaceable></optional></term>
<listitem>
<para>List unit files installed on the system, in combination with their enablement state (as reported by
<variablelist>
<varlistentry>
- <term><command>list-machines <optional><replaceable>PATTERN</replaceable>…</optional></command></term>
+ <term><command>list-machines</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
<listitem>
<para>List the host and all running local containers with
</listitem>
</varlistentry>
<varlistentry>
- <term><command>reboot <optional><replaceable>arg</replaceable></optional></command></term>
+ <term><command>reboot</command> <optional><replaceable>arg</replaceable></optional></term>
<listitem>
<para>Shut down and reboot the system. This is mostly equivalent to <command>systemctl start reboot.target
</varlistentry>
<varlistentry>
- <term><command>exit <optional><replaceable>EXIT_CODE</replaceable></optional></command></term>
+ <term><command>exit</command> <optional><replaceable>EXIT_CODE</replaceable></optional></term>
<listitem>
<para>Ask the service manager to quit. This is only supported for user service managers (i.e. in
</varlistentry>
<varlistentry>
- <term><command>switch-root <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></command></term>
+ <term><command>switch-root</command> <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></term>
<listitem>
<para>Switches to a different root directory and executes a new system manager process below it. This is
projects / thirdparty / systemd.git / blobdiff