<term><option>--job-mode=</option></term>
<listitem>
- <para>When queuing a new job, control how to deal with already
- queued jobs. Takes one of <literal>fail</literal>,
+ <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>,
applications.</para>
<para><literal>ignore-requirements</literal> is similar to
- <literal>ignore-dependencies</literal> but only causes the
+ <literal>ignore-dependencies</literal>, but only causes the
requirement dependencies to be ignored, the ordering
dependencies will still be honoured.</para>
</listitem>
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 if privileged or not) and a list of active locks
+ (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
with identical immediate effects, however, since the latter
is lost on reboot, the changes are lost too.</para>
- <para>Similar, when used with
+ <para>Similarly, when used with
<command>set-property</command>, make changes only
temporarily, so that they are lost on the next
reboot.</para>
<term><command>list-sockets <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
<listitem>
- <para>List socket units ordered by the listening address.
+ <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
</varlistentry>
<varlistentry>
- <term><command>start <replaceable>NAME</replaceable>...</command></term>
+ <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>NAME</replaceable>...</command></term>
+ <term><command>stop <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Stop (deactivate) one or more units specified on the
</listitem>
</varlistentry>
<varlistentry>
- <term><command>reload <replaceable>NAME</replaceable>...</command></term>
+ <term><command>reload <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Asks all units listed on the command line to reload
</varlistentry>
<varlistentry>
- <term><command>restart <replaceable>NAME</replaceable>...</command></term>
+ <term><command>restart <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Restart one or more units specified on the command
</listitem>
</varlistentry>
<varlistentry>
- <term><command>try-restart <replaceable>NAME</replaceable>...</command></term>
+ <term><command>try-restart <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Restart one or more units specified on the command
</listitem>
</varlistentry>
<varlistentry>
- <term><command>reload-or-restart <replaceable>NAME</replaceable>...</command></term>
+ <term><command>reload-or-restart <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Reload one or more units if they support it. If not,
</listitem>
</varlistentry>
<varlistentry>
- <term><command>reload-or-try-restart <replaceable>NAME</replaceable>...</command></term>
+ <term><command>reload-or-try-restart <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Reload one or more units if they support it. If not,
</listitem>
</varlistentry>
<varlistentry>
- <term><command>kill <replaceable>NAME</replaceable>...</command></term>
+ <term><command>kill <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Send a signal to one or more processes of the
</listitem>
</varlistentry>
<varlistentry>
- <term><command>is-active <replaceable>NAME</replaceable>...</command></term>
+ <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 0 if at least one is
- active, non-zero otherwise. Unless <option>--quiet</option>
+ active, or non-zero otherwise. Unless <option>--quiet</option>
is specified, this will also print the current unit state to
STDOUT.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><command>is-failed <replaceable>NAME</replaceable>...</command></term>
+ <term><command>is-failed <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Check whether any of the specified units are in a "failed" state.
</listitem>
</varlistentry>
<varlistentry>
- <term><command>status</command> <optional><replaceable>NAME</replaceable>...|<replaceable>PID</replaceable>...]</optional></term>
+ <term><command>status</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...]</optional></term>
<listitem>
<para>Show terse runtime status information about one or
</listitem>
</varlistentry>
<varlistentry>
- <term><command>show</command> <optional><replaceable>NAME</replaceable>...|<replaceable>JOB</replaceable>...</optional></term>
+ <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
</listitem>
</varlistentry>
<varlistentry>
- <term><command>cat <replaceable>NAME</replaceable>...</command></term>
+ <term><command>cat <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Show backing files of one or more units. Prints the
</varlistentry>
<varlistentry>
- <term><command>help <replaceable>NAME</replaceable>...|<replaceable>PID</replaceable>...</command></term>
+ <term><command>help <replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...</command></term>
<listitem>
<para>Show manual pages for one or more units, if
</varlistentry>
<varlistentry>
- <term><command>reset-failed [<replaceable>NAME</replaceable>...]</command></term>
+ <term><command>reset-failed [<replaceable>PATTERN</replaceable>...]</command></term>
<listitem>
<para>Reset the <literal>failed</literal> state of the
<row>
<entry><literal>static</literal></entry>
<entry>Unit is not enabled, but has no provisions for enabling in [Install] section</entry>
- <entry>1</entry>
+ <entry>0</entry>
</row>
<row>
<entry><literal>disabled</literal></entry>
</listitem>
</varlistentry>
<varlistentry>
- <term><command>delete <replaceable>NAME</replaceable>...</command></term>
+ <term><command>delete <replaceable>PATTERN</replaceable>...</command></term>
<listitem>
<para>Remove a snapshot previously created with
specified value.</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><command>import-environment <replaceable>VARIABLE</replaceable>...</command></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>Parameter Syntax</title>
- <para>For unit commands the specified
- <replaceable>NAME</replaceable> should be the full name of the
- unit, or an abbreviated name which is automatically extended with
- the <literal>.service</literal> suffix.
- <programlisting># systemctl start foo.service</programlisting> is equivalent to:
- <programlisting># systemctl start foo</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> is equivalent to:
- <programlisting># systemctl status dev-sda.device
-# systemctl status home.mount</programlisting></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 link /path/to/foo.service</programlisting>
- </para>
+ <para>Unit ommands 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 snapshot-11</programlisting>
+ and
+ <programlisting># systemctl isolate snapshot-11.snapshot</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, and 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><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><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ for more details. The patterns are matched against the names of
+ currently loaded units, and patterns which don't 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>
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
</para>
</refsect1>