mirror of
https://github.com/systemd/systemd.git
synced 2024-12-25 01:34:28 +03:00
9391a1c3d6
If the EDITOR environment variable is not set, the Debian policy recommends to use the /usr/bin/editor program as default editor. This file is managed via the dpkg alternatives mechanism and typically used in Debian/Ubuntu and derivatives to configure the default editor. See section 11.4 of the Debian policy [1]. Therefor prefer /usr/bin/editor over specific editors if available. [1] https://www.debian.org/doc/debian-policy/ch-customized-programs.html
1765 lines
74 KiB
XML
1765 lines
74 KiB
XML
<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
|
|
<!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" >
|
|
%entities;
|
|
]>
|
|
|
|
<!--
|
|
This file is part of systemd.
|
|
|
|
Copyright 2010 Lennart Poettering
|
|
|
|
systemd is free software; you can redistribute it and/or modify it
|
|
under the terms of the GNU Lesser General Public License as published by
|
|
the Free Software Foundation; either version 2.1 of the License, or
|
|
(at your option) any later version.
|
|
|
|
systemd is distributed in the hope that it will be useful, but
|
|
WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
Lesser General Public License for more details.
|
|
|
|
You should have received a copy of the GNU Lesser General Public License
|
|
along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|
-->
|
|
|
|
<refentry id="systemctl"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<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>
|
|
<refentrytitle>systemctl</refentrytitle>
|
|
<manvolnum>1</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemctl</refname>
|
|
<refpurpose>Control the systemd system and service manager</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemctl</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="plain">COMMAND</arg>
|
|
<arg choice="opt" rep="repeat">NAME</arg>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemctl</command> may be used to introspect and
|
|
control the state of the <literal>systemd</literal> system and
|
|
service manager. Please refer to
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
for an introduction into the basic concepts and functionality this
|
|
tool manages.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>-t</option></term>
|
|
<term><option>--type=</option></term>
|
|
|
|
<listitem>
|
|
<para>The argument should be a comma-separated list of unit
|
|
types such as <option>service</option> and
|
|
<option>socket</option>.
|
|
</para>
|
|
|
|
<para>If one of the arguments is a unit type, when listing
|
|
units, limit display to certain unit types. Otherwise, units
|
|
of all types will be shown.</para>
|
|
|
|
<para>As a special case, if one of the arguments is
|
|
<option>help</option>, a list of allowed values will be
|
|
printed and the program will exit.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--state=</option></term>
|
|
|
|
<listitem>
|
|
<para>The argument should be a comma-separated list of unit
|
|
LOAD, SUB, or ACTIVE states. When listing units, show only
|
|
those in specified states. Use <option>--state=failed</option>
|
|
to show only failed units.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-p</option></term>
|
|
<term><option>--property=</option></term>
|
|
|
|
<listitem>
|
|
<para>When showing unit/job/manager properties with the
|
|
<command>show</command> command, limit display to certain
|
|
properties as specified as argument. If not specified, all
|
|
set properties are shown. The argument should be a
|
|
comma-separated list of property names, such as
|
|
<literal>MainPID</literal>. If specified more than once, all
|
|
properties with the specified names are shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-a</option></term>
|
|
<term><option>--all</option></term>
|
|
|
|
<listitem>
|
|
<para>When listing units, show all loaded units, regardless
|
|
of their state, including inactive units. When showing
|
|
unit/job/manager properties, show all properties regardless
|
|
whether they are set or not.</para>
|
|
<para>To list all units installed on the system, use the
|
|
<command>list-unit-files</command> command instead.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-r</option></term>
|
|
<term><option>--recursive</option></term>
|
|
|
|
<listitem>
|
|
<para>When listing units, also show units of local
|
|
containers. Units of local containers will be prefixed with
|
|
the container name, separated by a single colon character
|
|
(<literal>:</literal>).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--reverse</option></term>
|
|
|
|
<listitem>
|
|
<para>Show reverse dependencies between units with
|
|
<command>list-dependencies</command>, i.e. follow
|
|
dependencies of type <varname>WantedBy=</varname>,
|
|
<varname>RequiredBy=</varname>,
|
|
<varname>RequiredByOverridable=</varname>,
|
|
<varname>PartOf=</varname>, <varname>BoundBy=</varname>,
|
|
instead of <varname>Wants=</varname> and similar.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--after</option></term>
|
|
|
|
<listitem>
|
|
<para>With <command>list-dependencies</command>, show the
|
|
units that are ordered before the specified unit. In other
|
|
words, recursively list units following the
|
|
<varname>After=</varname> dependency.</para>
|
|
|
|
<para>Note that any <varname>After=</varname> dependency is
|
|
automatically mirrored to create a
|
|
<varname>Before=</varname> dependency. Temporal dependencies
|
|
may be specified explicitly, but are also created implicitly
|
|
for units which are <varname>WantedBy=</varname> targets
|
|
(see
|
|
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
|
|
and as a result of other directives (for example
|
|
<varname>RequiresMountsFor=</varname>). Both explicitly
|
|
and implicitly introduced dependencies are shown with
|
|
<command>list-dependencies</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--before</option></term>
|
|
|
|
<listitem>
|
|
<para>With <command>list-dependencies</command>, show the
|
|
units that are ordered after the specified unit. In other
|
|
words, recursively list units following the
|
|
<varname>Before=</varname> dependency.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-l</option></term>
|
|
<term><option>--full</option></term>
|
|
|
|
<listitem>
|
|
<para>Do not ellipsize unit names, process tree entries,
|
|
journal output, or truncate unit descriptions in the output
|
|
of <command>status</command>, <command>list-units</command>,
|
|
<command>list-jobs</command>, and
|
|
<command>list-timers</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--show-types</option></term>
|
|
|
|
<listitem>
|
|
<para>When showing sockets, show the type of the socket.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<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> or
|
|
<literal>flush</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.</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 honoured.</para>
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-i</option></term>
|
|
<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>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-q</option></term>
|
|
<term><option>--quiet</option></term>
|
|
|
|
<listitem>
|
|
<para>Suppress output to standard output in
|
|
<command>snapshot</command>,
|
|
<command>is-active</command>,
|
|
<command>is-failed</command>,
|
|
<command>is-enabled</command>,
|
|
<command>is-system-running</command>,
|
|
<command>enable</command> and
|
|
<command>disable</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--no-block</option></term>
|
|
|
|
<listitem>
|
|
<para>Do not synchronously wait for the requested operation
|
|
to finish. If this is not specified, the job will be
|
|
verified, enqueued and <command>systemctl</command> will
|
|
wait until the unit's start-up is completed. By passing this
|
|
argument, it is only verified and enqueued.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="user-system-options.xml" xpointer="user" />
|
|
<xi:include href="user-system-options.xml" xpointer="system" />
|
|
|
|
<!-- we do not document -failed here, as it has been made
|
|
redundant by -state=failed, which it predates. To keep
|
|
things simple we only document the new switch, while
|
|
keeping the old one around for compatibility only. -->
|
|
|
|
<varlistentry>
|
|
<term><option>--no-wall</option></term>
|
|
|
|
<listitem>
|
|
<para>Do not send wall message before halt, power-off,
|
|
reboot.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--global</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>enable</command> and
|
|
<command>disable</command>, operate on the global user
|
|
configuration directory, thus enabling or disabling a unit
|
|
file globally for all future logins of all users.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--no-reload</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>enable</command> and
|
|
<command>disable</command>, do not implicitly reload daemon
|
|
configuration after executing the changes.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--no-ask-password</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>start</command> and related
|
|
commands, disables asking for passwords. Background services
|
|
may require input of a password or passphrase string, for
|
|
example to unlock system hard disks or cryptographic
|
|
certificates. Unless this option is specified and the
|
|
command is invoked from a terminal,
|
|
<command>systemctl</command> will query the user on the
|
|
terminal for the necessary secrets. Use this option to
|
|
switch this behavior off. In this case, the password must be
|
|
supplied by some other means (for example graphical password
|
|
agents) or the service might fail. This also disables
|
|
querying the user for authentication for privileged
|
|
operations.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--kill-who=</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>kill</command>, choose which
|
|
processes to send a signal to. Must be one of
|
|
<option>main</option>, <option>control</option> or
|
|
<option>all</option> to select whether to kill only the main
|
|
process, the control process or all processes of the
|
|
unit. The main process of the unit is the one that defines
|
|
the life-time of it. A control process of a unit is one that
|
|
is invoked by the manager to induce state changes of it. For
|
|
example, all processes started due to the
|
|
<varname>ExecStartPre=</varname>,
|
|
<varname>ExecStop=</varname> or
|
|
<varname>ExecReload=</varname> settings of service units are
|
|
control processes. Note that there is only one control
|
|
process per unit at a time, as only one state change is
|
|
executed at a time. For services of type
|
|
<varname>Type=forking</varname>, the initial process started
|
|
by the manager for <varname>ExecStart=</varname> is a
|
|
control process, while the process ultimately forked off by
|
|
that one is then considered the main process of the unit (if
|
|
it can be determined). This is different for service units
|
|
of other types, where the process forked off by the manager
|
|
for <varname>ExecStart=</varname> is always the main process
|
|
itself. A service unit consists of zero or one main process,
|
|
zero or one control process plus any number of additional
|
|
processes. Not all unit types manage processes of these
|
|
types however. For example, for mount units, control processes
|
|
are defined (which are the invocations of
|
|
<filename>&MOUNT_PATH;</filename> and
|
|
<filename>&UMOUNT_PATH;</filename>), but no main process
|
|
is defined. If omitted, defaults to
|
|
<option>all</option>.</para>
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-s</option></term>
|
|
<term><option>--signal=</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>kill</command>, choose which
|
|
signal to send to selected processes. Must be one of the
|
|
well known signal specifiers such as <constant>SIGTERM</constant>, <constant>SIGINT</constant> or
|
|
<constant>SIGSTOP</constant>. If omitted, defaults to
|
|
<option>SIGTERM</option>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-f</option></term>
|
|
<term><option>--force</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>enable</command>, overwrite
|
|
any existing conflicting symlinks.</para>
|
|
|
|
<para>When used with <command>halt</command>,
|
|
<command>poweroff</command>, <command>reboot</command> or
|
|
<command>kexec</command>, execute the selected operation
|
|
without shutting down all units. However, all processes will
|
|
be killed forcibly and all file systems are unmounted or
|
|
remounted read-only. This is hence a drastic but relatively
|
|
safe option to request an immediate reboot. If
|
|
<option>--force</option> is specified twice for these
|
|
operations, they will be executed immediately without
|
|
terminating any processes or unmounting any file
|
|
systems. Warning: specifying <option>--force</option> twice
|
|
with any of these operations might result in data
|
|
loss.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--now</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>enable</command>, the units
|
|
will also be started. When used with <command>disable</command> or
|
|
<command>mask</command>, the units will also be stopped. The start
|
|
or stop operation is only carried out when the respective enable or
|
|
disable operation has been successful.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--root=</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with
|
|
<command>enable</command>/<command>disable</command>/<command>is-enabled</command>
|
|
(and related commands), use alternative root path when
|
|
looking for unit files.</para>
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--runtime</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>enable</command>,
|
|
<command>disable</command>, <command>edit</command>,
|
|
(and related commands), make changes only temporarily, so
|
|
that they are lost on the next reboot. This will have the
|
|
effect that changes are not made in subdirectories of
|
|
<filename>/etc</filename> but in <filename>/run</filename>,
|
|
with identical immediate effects, however, since the latter
|
|
is lost on reboot, the changes are lost too.</para>
|
|
|
|
<para>Similarly, when used with
|
|
<command>set-property</command>, make changes only
|
|
temporarily, so that they are lost on the next
|
|
reboot.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--preset-mode=</option></term>
|
|
|
|
<listitem>
|
|
<para>Takes one of <literal>full</literal> (the default),
|
|
<literal>enable-only</literal>,
|
|
<literal>disable-only</literal>. When used with the
|
|
<command>preset</command> or <command>preset-all</command>
|
|
commands, controls whether units shall be disabled and
|
|
enabled according to the preset rules, or only enabled, or
|
|
only disabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-n</option></term>
|
|
<term><option>--lines=</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>status</command>, controls the
|
|
number of journal lines to show, counting from the most
|
|
recent ones. Takes a positive integer argument. Defaults to
|
|
10.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-o</option></term>
|
|
<term><option>--output=</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>status</command>, controls the
|
|
formatting of the journal entries that are shown. For the
|
|
available choices, see
|
|
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
|
Defaults to <literal>short</literal>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--firmware-setup</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with the <command>reboot</command> command,
|
|
indicate to the system's firmware to boot into setup
|
|
mode. Note that this is currently only supported on some EFI
|
|
systems and only if the system was booted in EFI
|
|
mode.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--plain</option></term>
|
|
|
|
<listitem>
|
|
<para>When used with <command>list-dependencies</command>,
|
|
the output is printed as a list instead of a tree.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="user-system-options.xml" xpointer="host" />
|
|
<xi:include href="user-system-options.xml" xpointer="machine" />
|
|
|
|
<xi:include href="standard-options.xml" xpointer="no-pager" />
|
|
<xi:include href="standard-options.xml" xpointer="no-legend" />
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Commands</title>
|
|
|
|
<para>The following commands are understood:</para>
|
|
|
|
<refsect2>
|
|
<title>Unit Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>list-units <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
|
|
|
|
<listitem>
|
|
<para>List known units (subject to limitations specified
|
|
with <option>-t</option>). If one or more
|
|
<replaceable>PATTERN</replaceable>s are specified, only
|
|
units matching one of them are shown.</para>
|
|
|
|
<para>This is the default command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>list-sockets <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
|
|
|
|
<listitem>
|
|
<para>List socket units ordered by listening address.
|
|
If one or more <replaceable>PATTERN</replaceable>s are
|
|
specified, only socket units matching one of them are
|
|
shown. Produces output similar to
|
|
<programlisting>
|
|
LISTEN UNIT ACTIVATES
|
|
/dev/initctl systemd-initctl.socket systemd-initctl.service
|
|
...
|
|
[::]:22 sshd.socket sshd.service
|
|
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
|
|
|
5 sockets listed.</programlisting>
|
|
Note: because the addresses might contains spaces, this output
|
|
is not suitable for programmatic consumption.
|
|
</para>
|
|
|
|
<para>See also the options <option>--show-types</option>,
|
|
<option>--all</option>, and <option>--state=</option>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>list-timers <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
|
|
|
|
<listitem>
|
|
<para>List timer units ordered by the time they elapse
|
|
next. If one or more <replaceable>PATTERN</replaceable>s
|
|
are specified, only units matching one of them are shown.
|
|
</para>
|
|
|
|
<para>See also the options <option>--all</option> and
|
|
<option>--state=</option>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>start <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Start (activate) one or more units specified on the
|
|
command line.</para>
|
|
|
|
<para>Note that glob patterns operate on a list of currently
|
|
loaded units. Units which are not active and are not in a
|
|
failed state usually are not loaded, and would not be
|
|
matched by any pattern. In addition, in case of
|
|
instantiated units, systemd is often unaware of the
|
|
instance name until the instance has been started. Therefore,
|
|
using glob patterns with <command>start</command>
|
|
has limited usefulness.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>stop <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Stop (deactivate) one or more units specified on the
|
|
command line.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>reload <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Asks all units listed on the command line to reload
|
|
their configuration. Note that this will reload the
|
|
service-specific configuration, not the unit configuration
|
|
file of systemd. If you want systemd to reload the
|
|
configuration file of a unit, use the
|
|
<command>daemon-reload</command> command. In other words:
|
|
for the example case of Apache, this will reload Apache's
|
|
<filename>httpd.conf</filename> in the web server, not the
|
|
<filename>apache.service</filename> systemd unit
|
|
file.</para>
|
|
|
|
<para>This command should not be confused with the
|
|
<command>daemon-reload</command> command.</para>
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>restart <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Restart one or more units specified on the command
|
|
line. If the units are not running yet, they will be
|
|
started.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>try-restart <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Restart one or more units specified on the command
|
|
line if the units are running. This does nothing if units are not
|
|
running. Note that, for compatibility with Red Hat init
|
|
scripts, <command>condrestart</command> is equivalent to this
|
|
command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>reload-or-restart <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Reload one or more units if they support it. If not,
|
|
restart them instead. If the units are not running yet, they
|
|
will be started.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>reload-or-try-restart <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Reload one or more units if they support it. If not,
|
|
restart them instead. This does nothing if the units are not
|
|
running. Note that, for compatibility with SysV init scripts,
|
|
<command>force-reload</command> is equivalent to this
|
|
command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>isolate <replaceable>NAME</replaceable></command></term>
|
|
|
|
<listitem>
|
|
<para>Start the unit specified on the command line and its
|
|
dependencies and stop all others. If a unit name with no
|
|
extension is given, an extension of
|
|
<literal>.target</literal> will be assumed.</para>
|
|
|
|
<para>This is similar to changing the runlevel in a
|
|
traditional init system. The <command>isolate</command>
|
|
command will immediately stop processes that are not enabled
|
|
in the new unit, possibly including the graphical
|
|
environment or terminal you are currently using.</para>
|
|
|
|
<para>Note that this is allowed only on units where
|
|
<option>AllowIsolate=</option> is enabled. See
|
|
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
for details.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>kill <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Send a signal to one or more processes of the
|
|
unit. Use <option>--kill-who=</option> to select which
|
|
process to kill. Use <option>--signal=</option> to select
|
|
the signal to send.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>is-active <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Check whether any of the specified units are active
|
|
(i.e. running). Returns an exit code
|
|
<constant>0</constant> if at least one is active, or
|
|
non-zero otherwise. Unless <option>--quiet</option> is
|
|
specified, this will also print the current unit state to
|
|
standard output.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>is-failed <replaceable>PATTERN</replaceable>...</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>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>status</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...]</optional></term>
|
|
|
|
<listitem>
|
|
<para>Show terse runtime status information about one or
|
|
more units, followed by most recent log data from the
|
|
journal. If no units are specified, show system status. If
|
|
combined with <option>--all</option>, also show the status of
|
|
all units (subject to limitations specified with
|
|
<option>-t</option>). If a PID is passed, show information
|
|
about the unit the process belongs to.</para>
|
|
|
|
<para>This function is intended to generate human-readable
|
|
output. If you are looking for computer-parsable output,
|
|
use <command>show</command> instead. By default this
|
|
function only shows 10 lines of output and ellipsizes
|
|
lines to fit in the terminal window. This can be changes
|
|
with <option>--lines</option> and <option>--full</option>,
|
|
see above. In addition, <command>journalctl
|
|
--unit=<replaceable>NAME</replaceable></command> or
|
|
<command>journalctl
|
|
--user-unit=<replaceable>NAME</replaceable></command> use
|
|
a similar filter for messages and might be more
|
|
convenient.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>show</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>JOB</replaceable>...</optional></term>
|
|
|
|
<listitem>
|
|
<para>Show properties of one or more units, jobs, or the
|
|
manager itself. If no argument is specified, properties of
|
|
the manager will be shown. If a unit name is specified,
|
|
properties of the unit is shown, and if a job id is
|
|
specified, properties of the job is shown. By default, empty
|
|
properties are suppressed. Use <option>--all</option> to
|
|
show those too. To select specific properties to show, use
|
|
<option>--property=</option>. This command is intended to be
|
|
used whenever computer-parsable output is required. Use
|
|
<command>status</command> if you are looking for formatted
|
|
human-readable output.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>cat <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Show backing files of one or more units. Prints the
|
|
"fragment" and "drop-ins" (source files) of units. Each
|
|
file is preceded by a comment which includes the file
|
|
name.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>set-property <replaceable>NAME</replaceable> <replaceable>ASSIGNMENT</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Set the specified unit properties at runtime where
|
|
this is supported. This allows changing configuration
|
|
parameter properties such as resource control settings at
|
|
runtime. Not all properties may be changed at runtime, but
|
|
many resource control settings (primarily those in
|
|
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
|
|
may. The changes are applied instantly, and stored on disk
|
|
for future boots, unless <option>--runtime</option> is
|
|
passed, in which case the settings only apply until the
|
|
next reboot. The syntax of the property assignment follows
|
|
closely the syntax of assignments in unit files.</para>
|
|
|
|
<para>Example: <command>systemctl set-property foobar.service CPUShares=777</command></para>
|
|
|
|
<para>Note that this command allows changing multiple
|
|
properties at the same time, which is preferable over
|
|
setting them individually. Like unit file configuration
|
|
settings, assigning the empty list to list parameters will
|
|
reset the list.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>help <replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Show manual pages for one or more units, if
|
|
available. If a PID is given, the manual pages for the unit
|
|
the process belongs to are shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>reset-failed [<replaceable>PATTERN</replaceable>...]</command></term>
|
|
|
|
<listitem>
|
|
<para>Reset the <literal>failed</literal> state of the
|
|
specified units, or if no unit name is passed, reset the state of all
|
|
units. When a unit fails in some way (i.e. process exiting
|
|
with non-zero error code, terminating abnormally or timing
|
|
out), it will automatically enter the
|
|
<literal>failed</literal> state and its exit code and status
|
|
is recorded for introspection by the administrator until the
|
|
service is restarted or reset with this command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>
|
|
<command>list-dependencies</command>
|
|
<optional><replaceable>NAME</replaceable></optional>
|
|
</term>
|
|
|
|
<listitem>
|
|
<para>Shows units required and wanted by the specified
|
|
unit. This recursively lists units following the
|
|
<varname>Requires=</varname>,
|
|
<varname>RequiresOverridable=</varname>,
|
|
<varname>Requisite=</varname>,
|
|
<varname>RequisiteOverridable=</varname>,
|
|
<varname>Wants=</varname>, <varname>BindsTo=</varname>
|
|
dependencies. If no unit is specified,
|
|
<filename>default.target</filename> is implied.</para>
|
|
|
|
<para>By default, only target units are recursively
|
|
expanded. When <option>--all</option> is passed, all other
|
|
units are recursively expanded as well.</para>
|
|
|
|
<para>Options <option>--reverse</option>,
|
|
<option>--after</option>, <option>--before</option>
|
|
may be used to change what types of dependencies
|
|
are shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Unit File Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>list-unit-files <optional><replaceable>PATTERN...</replaceable></optional></command></term>
|
|
|
|
<listitem>
|
|
<para>List installed unit files. If one or more
|
|
<replaceable>PATTERN</replaceable>s are specified, only
|
|
units whose filename (just the last component of the path)
|
|
matches one of them are shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>enable <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Enable one or more unit files or unit file instances,
|
|
as specified on the command line. This will create a number
|
|
of symlinks as encoded in the <literal>[Install]</literal>
|
|
sections of the unit files. After the symlinks have been
|
|
created, the systemd configuration is reloaded (in a way that
|
|
is equivalent to <command>daemon-reload</command>) to ensure
|
|
the changes are taken into account immediately. Note that
|
|
this does <emphasis>not</emphasis> have the effect of also
|
|
starting any of the units being enabled. If this
|
|
is desired, either <option>--now</option> should be used
|
|
together with this command, or an additional <command>start</command>
|
|
command must be invoked for the unit. Also note that in case of
|
|
instance enablement, symlinks named the same as instances
|
|
are created in the install location, however they all point to the
|
|
same template unit file.</para>
|
|
|
|
<para>This command will print the actions executed. This
|
|
output may be suppressed by passing <option>--quiet</option>.
|
|
</para>
|
|
|
|
<para>Note that this operation creates only the suggested
|
|
symlinks for the units. While this command is the
|
|
recommended way to manipulate the unit configuration
|
|
directory, the administrator is free to make additional
|
|
changes manually by placing or removing symlinks in the
|
|
directory. This is particularly useful to create
|
|
configurations that deviate from the suggested default
|
|
installation. In this case, the administrator must make sure
|
|
to invoke <command>daemon-reload</command> manually as
|
|
necessary to ensure the changes are taken into account.
|
|
</para>
|
|
|
|
<para>Enabling units should not be confused with starting
|
|
(activating) units, as done by the <command>start</command>
|
|
command. Enabling and starting units is orthogonal: units
|
|
may be enabled without being started and started without
|
|
being enabled. Enabling simply hooks the unit into various
|
|
suggested places (for example, so that the unit is
|
|
automatically started on boot or when a particular kind of
|
|
hardware is plugged in). Starting actually spawns the daemon
|
|
process (in case of service units), or binds the socket (in
|
|
case of socket units), and so on.</para>
|
|
|
|
<para>Depending on whether <option>--system</option>,
|
|
<option>--user</option>, <option>--runtime</option>,
|
|
or <option>--global</option> is specified, this enables the unit
|
|
for the system, for the calling user only, for only this boot of
|
|
the system, or for all future logins of all users, or only this
|
|
boot. Note that in the last case, no systemd daemon
|
|
configuration is reloaded.</para>
|
|
|
|
<para>Using <command>enable</command> on masked units
|
|
results in an error.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>disable <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Disables one or more units. This removes all symlinks
|
|
to the specified unit files from the unit configuration
|
|
directory, and hence undoes the changes made by
|
|
<command>enable</command>. Note however that this removes
|
|
all symlinks to the unit files (i.e. including manual
|
|
additions), not just those actually created by
|
|
<command>enable</command>. This call implicitly reloads the
|
|
systemd daemon configuration after completing the disabling
|
|
of the units. Note that this command does not implicitly
|
|
stop the units that are being disabled. If this is desired, either
|
|
<option>--now</option> should be used together with this command, or
|
|
an additional <command>stop</command> command should be executed
|
|
afterwards.</para>
|
|
|
|
<para>This command will print the actions executed. This
|
|
output may be suppressed by passing <option>--quiet</option>.
|
|
</para>
|
|
|
|
<para>This command honors <option>--system</option>,
|
|
<option>--user</option>, <option>--runtime</option> and
|
|
<option>--global</option> in a similar way as
|
|
<command>enable</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>reenable <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Reenable one or more unit files, as specified on the
|
|
command line. This is a combination of
|
|
<command>disable</command> and <command>enable</command> and
|
|
is useful to reset the symlinks a unit is enabled with to
|
|
the defaults configured in the <literal>[Install]</literal>
|
|
section of the unit file.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>preset <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Reset one or more unit files, as specified on the
|
|
command line, to the defaults configured in the preset
|
|
policy files. This has the same effect as
|
|
<command>disable</command> or <command>enable</command>,
|
|
depending how the unit is listed in the preset files.</para>
|
|
|
|
<para>Use <option>--preset-mode=</option> to control
|
|
whether units shall be enabled and disabled, or only
|
|
enabled, or only disabled.</para>
|
|
|
|
<para>For more information on the preset policy format,
|
|
see
|
|
<citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
For more information on the concept of presets, please
|
|
consult the <ulink
|
|
url="http://freedesktop.org/wiki/Software/systemd/Preset">Preset</ulink>
|
|
document.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>preset-all</command></term>
|
|
|
|
<listitem>
|
|
<para>Resets all installed unit files to the defaults
|
|
configured in the preset policy file (see above).</para>
|
|
|
|
<para>Use <option>--preset-mode=</option> to control
|
|
whether units shall be enabled and disabled, or only
|
|
enabled, or only disabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>is-enabled <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Checks whether any of the specified unit files are
|
|
enabled (as with <command>enable</command>). Returns an
|
|
exit code of 0 if at least one is enabled, non-zero
|
|
otherwise. Prints the current enable status (see table).
|
|
To suppress this output, use <option>--quiet</option>.
|
|
</para>
|
|
|
|
<table>
|
|
<title>
|
|
<command>is-enabled</command> output
|
|
</title>
|
|
|
|
<tgroup cols='3'>
|
|
<thead>
|
|
<row>
|
|
<entry>Printed string</entry>
|
|
<entry>Meaning</entry>
|
|
<entry>Return value</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>enabled</literal></entry>
|
|
<entry morerows='1'>Enabled through a symlink in <filename>.wants</filename> directory (permanently or just in <filename>/run</filename>).</entry>
|
|
<entry morerows='1'>0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>enabled-runtime</literal></entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>linked</literal></entry>
|
|
<entry morerows='1'>Made available through a symlink to the unit file (permanently or just in <filename>/run</filename>).</entry>
|
|
<entry morerows='1'>1</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>linked-runtime</literal></entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>masked</literal></entry>
|
|
<entry morerows='1'>Disabled entirely (permanently or just in <filename>/run</filename>).</entry>
|
|
<entry morerows='1'>1</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>masked-runtime</literal></entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>static</literal></entry>
|
|
<entry>Unit file is not enabled, and has no provisions for enabling in the <literal>[Install]</literal> section.</entry>
|
|
<entry>0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>indirect</literal></entry>
|
|
<entry>Unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the <literal>[Install]</literal> section, listing other unit files that might be enabled.</entry>
|
|
<entry>0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>disabled</literal></entry>
|
|
<entry>Unit file is not enabled.</entry>
|
|
<entry>1</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>mask <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Mask one or more unit files, as specified on the
|
|
command line. This will link these units to
|
|
<filename>/dev/null</filename>, making it impossible to
|
|
start them. This is a stronger version of
|
|
<command>disable</command>, since it prohibits all kinds of
|
|
activation of the unit, including enablement and manual
|
|
activation. Use this option with care. This honors the
|
|
<option>--runtime</option> option to only mask temporarily
|
|
until the next reboot of the system. The <option>--now</option>
|
|
option can be used to ensure that the units are also stopped.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>unmask <replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Unmask one or more unit files, as specified on the
|
|
command line. This will undo the effect of
|
|
<command>mask</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>link <replaceable>FILENAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Link a unit file that is not in the unit file search
|
|
paths into the unit file search path. This requires an
|
|
absolute path to a unit file. The effect of this can be
|
|
undone with <command>disable</command>. The effect of this
|
|
command is that a unit file is available for
|
|
<command>start</command> and other commands although it
|
|
is not installed directly in the unit search path.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>add-wants <replaceable>TARGET</replaceable>
|
|
<replaceable>NAME</replaceable>...</command></term>
|
|
<term><command>add-requires <replaceable>TARGET</replaceable>
|
|
<replaceable>NAME</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Adds <literal>Wants=</literal> resp. <literal>Requires=</literal>
|
|
dependency to the specified <replaceable>TARGET</replaceable> for
|
|
one or more units. </para>
|
|
|
|
<para>This command honors <option>--system</option>,
|
|
<option>--user</option>, <option>--runtime</option> and
|
|
<option>--global</option> in a similar way as
|
|
<command>enable</command>.</para>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>edit <replaceable>NAME</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>Depending on whether <option>--system</option> (the default),
|
|
<option>--user</option>, or <option>--global</option> is specified,
|
|
this 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, this will copy the
|
|
original units instead of creating drop-in files.</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 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
|
|
<filename>/run</filename>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>get-default</command></term>
|
|
|
|
<listitem>
|
|
<para>Return the default target to boot into. This returns
|
|
the target unit name <filename>default.target</filename>
|
|
is aliased (symlinked) to.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>set-default <replaceable>NAME</replaceable></command></term>
|
|
|
|
<listitem>
|
|
<para>Set the default target to boot into. This sets
|
|
(symlinks) the <filename>default.target</filename> alias
|
|
to the given target unit.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Machine Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>list-machines <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
|
|
|
|
<listitem>
|
|
<para>List the host and all running local containers with
|
|
their state. If one or more
|
|
<replaceable>PATTERN</replaceable>s are specified, only
|
|
containers matching one of them are shown.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Job Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>list-jobs <optional><replaceable>PATTERN...</replaceable></optional></command></term>
|
|
|
|
<listitem>
|
|
<para>List jobs that are in progress. If one or more
|
|
<replaceable>PATTERN</replaceable>s are specified, only
|
|
jobs for units matching one of them are shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>cancel <replaceable>JOB</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Cancel one or more jobs specified on the command line
|
|
by their numeric job IDs. If no job ID is specified, cancel
|
|
all pending jobs.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Snapshot Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>snapshot <optional><replaceable>NAME</replaceable></optional></command></term>
|
|
|
|
<listitem>
|
|
<para>Create a snapshot. If a snapshot name is specified,
|
|
the new snapshot will be named after it. If none is
|
|
specified, an automatic snapshot name is generated. In
|
|
either case, the snapshot name used is printed to standard
|
|
output, unless <option>--quiet</option> is specified.
|
|
</para>
|
|
|
|
<para>A snapshot refers to a saved state of the systemd
|
|
manager. It is implemented itself as a unit that is
|
|
generated dynamically with this command and has dependencies
|
|
on all units active at the time. At a later time, the user
|
|
may return to this state by using the
|
|
<command>isolate</command> command on the snapshot unit.
|
|
</para>
|
|
|
|
<para>Snapshots are only useful for saving and restoring
|
|
which units are running or are stopped, they do not
|
|
save/restore any other state. Snapshots are dynamic and lost
|
|
on reboot.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>delete <replaceable>PATTERN</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Remove a snapshot previously created with
|
|
<command>snapshot</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Environment Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>show-environment</command></term>
|
|
|
|
<listitem>
|
|
<para>Dump the systemd manager environment block. The
|
|
environment block will be dumped in straight-forward form
|
|
suitable for sourcing into a shell script. This environment
|
|
block will be passed to all processes the manager
|
|
spawns.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>set-environment <replaceable>VARIABLE=VALUE</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Set one or more systemd manager environment variables,
|
|
as specified on the command line.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>unset-environment <replaceable>VARIABLE</replaceable>...</command></term>
|
|
|
|
<listitem>
|
|
<para>Unset one or more systemd manager environment
|
|
variables. If only a variable name is specified, it will be
|
|
removed regardless of its value. If a variable and a value
|
|
are specified, the variable is only removed if it has the
|
|
specified value.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>
|
|
<command>import-environment</command>
|
|
<optional><replaceable>VARIABLE...</replaceable></optional>
|
|
</term>
|
|
|
|
<listitem>
|
|
<para>Import all, one or more environment variables set on
|
|
the client into the systemd manager environment block. If
|
|
no arguments are passed, the entire environment block is
|
|
imported. Otherwise, a list of one or more environment
|
|
variable names should be passed, whose client-side values
|
|
are then imported into the manager's environment
|
|
block.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Manager Lifecycle Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>daemon-reload</command></term>
|
|
|
|
<listitem>
|
|
<para>Reload systemd manager configuration. This will
|
|
rerun all generators (see
|
|
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
|
|
reload all unit files, and recreate the entire dependency
|
|
tree. While the daemon is being reloaded, all sockets
|
|
systemd listens on behalf of user configuration will stay
|
|
accessible.</para>
|
|
|
|
<para>This command should not be confused with the
|
|
<command>reload</command> command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>daemon-reexec</command></term>
|
|
|
|
<listitem>
|
|
<para>Reexecute the systemd manager. This will serialize the
|
|
manager state, reexecute the process and deserialize the
|
|
state again. This command is of little use except for
|
|
debugging and package upgrades. Sometimes, it might be
|
|
helpful as a heavy-weight <command>daemon-reload</command>.
|
|
While the daemon is being reexecuted, all sockets systemd listening
|
|
on behalf of user configuration will stay accessible.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>System Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>is-system-running</command></term>
|
|
|
|
<listitem>
|
|
<para>Checks whether the system is operational. This
|
|
returns success when the system is fully up and running,
|
|
meaning not in startup, shutdown or maintenance
|
|
mode. Failure is returned otherwise. In addition, the
|
|
current state is printed in a short string to standard
|
|
output, see table below. Use <option>--quiet</option> to
|
|
suppress this output.</para>
|
|
|
|
<table>
|
|
<title>Manager Operational States</title>
|
|
<tgroup cols='2'>
|
|
<colspec colname='name' />
|
|
<colspec colname='description' />
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><varname>initializing</varname></entry>
|
|
<entry><para>Early bootup, before
|
|
<filename>basic.target</filename> is reached
|
|
or the <varname>maintenance</varname> state entered.
|
|
</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><varname>starting</varname></entry>
|
|
<entry><para>Late bootup, before the job queue
|
|
becomes idle for the first time, or one of the
|
|
rescue targets are reached.</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><varname>running</varname></entry>
|
|
<entry><para>The system is fully
|
|
operational.</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><varname>degraded</varname></entry>
|
|
<entry><para>The system is operational but one or more
|
|
units failed.</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><varname>maintenance</varname></entry>
|
|
<entry><para>The rescue or emergency target is
|
|
active.</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><varname>stopping</varname></entry>
|
|
<entry><para>The manager is shutting
|
|
down.</para></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>default</command></term>
|
|
|
|
<listitem>
|
|
<para>Enter default mode. This is mostly equivalent to
|
|
<command>isolate default.target</command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>rescue</command></term>
|
|
|
|
<listitem>
|
|
<para>Enter rescue mode. This is mostly equivalent to
|
|
<command>isolate rescue.target</command>, but also prints a
|
|
wall message to all users.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>emergency</command></term>
|
|
|
|
<listitem>
|
|
<para>Enter emergency mode. This is mostly equivalent to
|
|
<command>isolate emergency.target</command>, but also prints
|
|
a wall message to all users.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>halt</command></term>
|
|
|
|
<listitem>
|
|
<para>Shut down and halt the system. This is mostly equivalent to
|
|
<command>start halt.target --job-mode=replace-irreversibly</command>, but also
|
|
prints a wall message to all users. If combined with
|
|
<option>--force</option>, shutdown of all running services is
|
|
skipped, however all processes are killed and all file
|
|
systems are unmounted or mounted read-only, immediately
|
|
followed by the system halt. If <option>--force</option> is
|
|
specified twice, the operation is immediately executed
|
|
without terminating any processes or unmounting any file
|
|
systems. This may result in data loss.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>poweroff</command></term>
|
|
|
|
<listitem>
|
|
<para>Shut down and power-off the system. This is mostly
|
|
equivalent to <command>start poweroff.target --job-mode=replace-irreversibly</command>,
|
|
but also prints a wall message to all users. If combined with
|
|
<option>--force</option>, shutdown of all running services is
|
|
skipped, however all processes are killed and all file
|
|
systems are unmounted or mounted read-only, immediately
|
|
followed by the powering off. If <option>--force</option> is
|
|
specified twice, the operation is immediately executed
|
|
without terminating any processes or unmounting any file
|
|
systems. This may result in data loss.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><command>reboot <optional><replaceable>arg</replaceable></optional></command></term>
|
|
|
|
<listitem>
|
|
<para>Shut down and reboot the system. This is mostly
|
|
equivalent to <command>start reboot.target --job-mode=replace-irreversibly</command>,
|
|
but also prints a wall message to all users. If combined with
|
|
<option>--force</option>, shutdown of all running services is
|
|
skipped, however all processes are killed and all file
|
|
systems are unmounted or mounted read-only, immediately
|
|
followed by the reboot. If <option>--force</option> is
|
|
specified twice, the operation is immediately executed
|
|
without terminating any processes or unmounting any file
|
|
systems. This may result in data loss.</para>
|
|
|
|
<para>If the optional argument
|
|
<replaceable>arg</replaceable> is given, it will be passed
|
|
as the optional argument to the
|
|
<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
|
system call. 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>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>kexec</command></term>
|
|
|
|
<listitem>
|
|
<para>Shut down and reboot the system via kexec. This is
|
|
mostly equivalent to <command>start kexec.target --job-mode=replace-irreversibly</command>,
|
|
but also prints a wall message to all users. If combined
|
|
with <option>--force</option>, shutdown of all running
|
|
services is skipped, however all processes are killed and
|
|
all file systems are unmounted or mounted read-only,
|
|
immediately followed by the reboot.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>exit</command></term>
|
|
|
|
<listitem>
|
|
<para>Ask the systemd manager to quit. This is only
|
|
supported for user service managers (i.e. in conjunction
|
|
with the <option>--user</option> option) and will fail
|
|
otherwise.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>switch-root <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></command></term>
|
|
|
|
<listitem>
|
|
<para>Switches to a different root directory and executes a
|
|
new system manager process below it. This is intended for
|
|
usage in initial RAM disks ("initrd"), and will transition
|
|
from the initrd's system manager process (a.k.a "init"
|
|
process) to the main system manager process. This call takes two
|
|
arguments: the directory that is to become the new root directory, and
|
|
the path to the new system manager binary below it to
|
|
execute as PID 1. If the latter is omitted or the empty
|
|
string, a systemd binary will automatically be searched for
|
|
and used as init. If the system manager path is omitted or
|
|
equal to the empty string, the state of the initrd's system
|
|
manager process is passed to the main system manager, which
|
|
allows later introspection of the state of the services
|
|
involved in the initrd boot.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>suspend</command></term>
|
|
|
|
<listitem>
|
|
<para>Suspend the system. This will trigger activation of
|
|
the special <filename>suspend.target</filename> target.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>hibernate</command></term>
|
|
|
|
<listitem>
|
|
<para>Hibernate the system. This will trigger activation of
|
|
the special <filename>hibernate.target</filename> target.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>hybrid-sleep</command></term>
|
|
|
|
<listitem>
|
|
<para>Hibernate and suspend the system. This will trigger
|
|
activation of the special
|
|
<filename>hybrid-sleep.target</filename> target.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect2>
|
|
|
|
<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, 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.
|
|
<programlisting># systemctl status /dev/sda
|
|
# systemctl status /home</programlisting>
|
|
are equivalent to:
|
|
<programlisting># systemctl status dev-sda.device
|
|
# systemctl status home.mount</programlisting>
|
|
In the second case, shell-style globs will be matched against
|
|
currently loaded units; literal unit names, with or without
|
|
a suffix, will be treated as in the first case. This means that
|
|
literal unit names always refer to exactly one unit, but globs
|
|
may match zero units and this is not considered an error.</para>
|
|
|
|
<para>Glob patterns use
|
|
<citerefentry project='man-pages'><refentrytitle>fnmatch</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
so normal shell-style globbing rules are used, and
|
|
<literal>*</literal>, <literal>?</literal>,
|
|
<literal>[]</literal> may be used. See
|
|
<citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
for more details. The patterns are matched against the names of
|
|
currently loaded units, and patterns which do not match anything
|
|
are silently skipped. For example:
|
|
<programlisting># systemctl stop sshd@*.service</programlisting>
|
|
will stop all <filename>sshd@.service</filename> instances.
|
|
</para>
|
|
|
|
<para>For unit file commands, the specified
|
|
<replaceable>NAME</replaceable> should be the full name of the
|
|
unit file, or the absolute path to the unit file:
|
|
<programlisting># systemctl enable foo.service</programlisting>
|
|
or
|
|
<programlisting># systemctl link /path/to/foo.service</programlisting>
|
|
</para>
|
|
</refsect2>
|
|
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned, a non-zero failure
|
|
code otherwise.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Environment</title>
|
|
|
|
<variablelist class='environment-variables'>
|
|
<varlistentry>
|
|
<term><varname>$SYSTEMD_EDITOR</varname></term>
|
|
|
|
<listitem><para>Editor to use when editing units; overrides
|
|
<varname>$EDITOR</varname> and <varname>$VISUAL</varname>. If neither
|
|
<varname>$SYSTEMD_EDITOR</varname> nor <varname>$EDITOR</varname> nor
|
|
<varname>$VISUAL</varname> are present or if it is set to an empty
|
|
string or if their execution failed, systemctl will try to execute well
|
|
known editors in this order:
|
|
<citerefentry project='die-net'><refentrytitle>editor</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry project='die-net'><refentrytitle>nano</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry project='die-net'><refentrytitle>vim</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry project='die-net'><refentrytitle>vi</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
<xi:include href="less-variables.xml" xpointer="pager"/>
|
|
<xi:include href="less-variables.xml" xpointer="less"/>
|
|
</refsect1>
|
|
|
|
<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>
|
|
</refsect1>
|
|
|
|
</refentry>
|