mirror of
https://github.com/systemd/systemd
synced 2024-07-01 07:34:28 +00:00
724 lines
36 KiB
XML
724 lines
36 KiB
XML
<?xml version='1.0'?>
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
|
|
<refentry id="systemd-run"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>systemd-run</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-run</refentrytitle>
|
|
<manvolnum>1</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-run</refname>
|
|
<refpurpose>Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemd-run</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="plain"><replaceable>COMMAND</replaceable>
|
|
<arg choice="opt" rep="repeat">ARGS</arg>
|
|
</arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-run</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="opt" rep="repeat">PATH OPTIONS</arg>
|
|
<arg choice="req"><replaceable>COMMAND</replaceable></arg>
|
|
<arg choice="opt" rep="repeat">ARGS</arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-run</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="opt" rep="repeat">SOCKET OPTIONS</arg>
|
|
<arg choice="req"><replaceable>COMMAND</replaceable></arg>
|
|
<arg choice="opt" rep="repeat">ARGS</arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-run</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="opt" rep="repeat">TIMER OPTIONS</arg>
|
|
<arg choice="req"><replaceable>COMMAND</replaceable></arg>
|
|
<arg choice="opt" rep="repeat">ARGS</arg>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-run</command> may be used to create and start a transient <filename>.service</filename> or
|
|
<filename>.scope</filename> unit and run the specified <replaceable>COMMAND</replaceable> in it. It may also be
|
|
used to create and start a transient <filename>.path</filename>, <filename>.socket</filename>, or
|
|
<filename>.timer</filename> unit, that activates a <filename>.service</filename> unit when elapsing.</para>
|
|
|
|
<para>If a command is run as transient service unit, it will be started and managed by the service manager like any
|
|
other service, and thus shows up in the output of <command>systemctl list-units</command> like any other unit. It
|
|
will run in a clean and detached execution environment, with the service manager as its parent process. In this
|
|
mode, <command>systemd-run</command> will start the service asynchronously in the background and return after the
|
|
command has begun execution (unless <option>--no-block</option>, <option>--wait</option>, <option>--pipe</option>,
|
|
or <option>--pty</option> are specified, see below).</para>
|
|
|
|
<para>If a command is run as transient scope unit, it will be executed by <command>systemd-run</command>
|
|
itself as parent process and will thus inherit the execution environment of the caller. However, the
|
|
processes of the command are managed by the service manager similarly to normal services, and will show
|
|
up in the output of <command>systemctl list-units</command>. Execution in this case is synchronous, and
|
|
will return only when the command finishes. This mode is enabled via the <option>--scope</option> switch
|
|
(see below).</para>
|
|
|
|
<para>If a command is run with path, socket, or timer options such as <option>--on-calendar=</option> (see below),
|
|
a transient path, socket, or timer unit is created alongside the service unit for the specified command. Only the
|
|
transient path, socket, or timer unit is started immediately, the transient service unit will be triggered by the
|
|
path, socket, or timer unit. If the <option>--unit=</option> option is specified, the
|
|
<replaceable>COMMAND</replaceable> may be omitted. In this case, <command>systemd-run</command> creates only a
|
|
<filename>.path</filename>, <filename>.socket</filename>, or <filename>.timer</filename> unit that triggers the
|
|
specified unit.</para>
|
|
|
|
<para>By default, services created with <command>systemd-run</command> default to the
|
|
<option>simple</option> type, see the description of <varname>Type=</varname> in
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
|
details. Note that when this type is used, the service manager (and thus the
|
|
<command>systemd-run</command> command) considers service start-up successful as soon as the
|
|
<function>fork()</function> for the main service process succeeded, i.e. before the
|
|
<function>execve()</function> is invoked, and thus even if the specified command cannot be started.
|
|
Consider using the <option>exec</option> service type (i.e. <option>--property=Type=exec</option>) to
|
|
ensure that <command>systemd-run</command> returns successfully only if the specified command line has
|
|
been successfully started.</para>
|
|
|
|
<para>After <command>systemd-run</command> passes the command to the service manager, the manager
|
|
performs variable expansion. This means that dollar characters (<literal>$</literal>) which should not be
|
|
expanded need to be escaped as <literal>$$</literal>. Expansion can also be disabled using
|
|
<varname>--expand-environment=no</varname>.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>--no-ask-password</option></term>
|
|
|
|
<listitem><para>Do not query the user for authentication for
|
|
privileged operations.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v226"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--scope</option></term>
|
|
|
|
<listitem>
|
|
<para>Create a transient <filename>.scope</filename> unit instead of the default transient
|
|
<filename>.service</filename> unit (see above).
|
|
</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v206"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--unit=</option></term>
|
|
<term><option>-u</option></term>
|
|
|
|
<listitem><para>Use this unit name instead of an automatically
|
|
generated one.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v206"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--property=</option></term>
|
|
<term><option>-p</option></term>
|
|
|
|
<listitem><para>Sets a property on the scope or service unit that is created. This option takes an assignment
|
|
in the same format as
|
|
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
|
<command>set-property</command> command.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v211"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--description=</option></term>
|
|
|
|
<listitem><para>Provide a description for the service, scope, path, socket, or timer unit. If not specified,
|
|
the command itself will be used as a description. See <varname>Description=</varname> in
|
|
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v206"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--slice=</option></term>
|
|
|
|
<listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part
|
|
of the specified slice, instead of <filename>system.slice</filename> (when running in
|
|
<option>--system</option> mode) or the root slice (when running in <option>--user</option>
|
|
mode).</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v206"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--slice-inherit</option></term>
|
|
|
|
<listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part
|
|
of the slice the <command>systemd-run</command> itself has been invoked in. This option may be
|
|
combined with <option>--slice=</option>, in which case the slice specified via
|
|
<option>--slice=</option> is placed within the slice the <command>systemd-run</command> command is
|
|
invoked in.</para>
|
|
|
|
<para>Example: consider <command>systemd-run</command> being invoked in the slice
|
|
<filename>foo.slice</filename>, and the <option>--slice=</option> argument is
|
|
<filename>bar</filename>. The unit will then be placed under
|
|
<filename>foo-bar.slice</filename>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v246"/>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--expand-environment=<replaceable>BOOL</replaceable></option></term>
|
|
|
|
<listitem><para>Expand environment variables in command arguments. If enabled, environment variables
|
|
specified as <literal>${<replaceable>VARIABLE</replaceable>}</literal> will be expanded in the same
|
|
way as in commands specified via <varname>ExecStart=</varname> in units. With
|
|
<varname>--scope</varname>, this expansion is performed by <command>systemd-run</command> itself, and
|
|
in other cases by the service manager that spawns the command. Note that this is similar to, but not
|
|
the same as variable expansion in
|
|
<citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
and other shells.</para>
|
|
|
|
<para>The default is to enable this option in all cases, except for <varname>--scope</varname> where
|
|
it is disabled by default, for backward compatibility reasons. Note that this will be changed in a
|
|
future release, where it will be switched to enabled by default as well.</para>
|
|
|
|
<para>See
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
for a description of variable expansion. Disabling variable expansion is useful if the specified
|
|
command includes or may include a <literal>$</literal> sign.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v254"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-r</option></term>
|
|
<term><option>--remain-after-exit</option></term>
|
|
|
|
<listitem><para>After the service process has terminated, keep the service around until it is explicitly
|
|
stopped. This is useful to collect runtime information about the service after it finished running. Also see
|
|
<varname>RemainAfterExit=</varname> in
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v207"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--send-sighup</option></term>
|
|
|
|
<listitem><para>When terminating the scope or service unit, send a SIGHUP immediately after SIGTERM. This is
|
|
useful to indicate to shells and shell-like processes that the connection has been severed. Also see
|
|
<varname>SendSIGHUP=</varname> in
|
|
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v207"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--service-type=</option></term>
|
|
|
|
<listitem><para>Sets the service type. Also see
|
|
<varname>Type=</varname> in
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
|
|
option has no effect in conjunction with
|
|
<option>--scope</option>. Defaults to
|
|
<constant>simple</constant>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v211"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--uid=</option></term>
|
|
<term><option>--gid=</option></term>
|
|
|
|
<listitem><para>Runs the service process under the specified UNIX user and group. Also see
|
|
<varname>User=</varname> and <varname>Group=</varname> in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v211"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--nice=</option></term>
|
|
|
|
<listitem><para>Runs the service process with the specified
|
|
nice level. Also see <varname>Nice=</varname> in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v211"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--working-directory=</option></term>
|
|
|
|
<listitem><para>Runs the service process with the specified working directory. Also see
|
|
<varname>WorkingDirectory=</varname> in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v240"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--same-dir</option></term>
|
|
<term><option>-d</option></term>
|
|
|
|
<listitem><para>Similar to <option>--working-directory=</option>, but uses the current working
|
|
directory of the caller for the service to execute.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v240"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-E <replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
|
|
<term><option>--setenv=<replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
|
|
|
|
<listitem><para>Runs the service process with the specified environment variable set. This parameter
|
|
may be used more than once to set multiple variables. When <literal>=</literal> and
|
|
<replaceable>VALUE</replaceable> are omitted, the value of the variable with the same name in the
|
|
program environment will be used.</para>
|
|
|
|
<para>Also see <varname>Environment=</varname> in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v211"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--pty</option></term>
|
|
<term><option>-t</option></term>
|
|
|
|
<listitem><para>When invoking the command, the transient service connects its standard input, output and error
|
|
to the terminal <command>systemd-run</command> is invoked on, via a pseudo TTY device. This allows running
|
|
programs that expect interactive user input/output as services, such as interactive command shells.</para>
|
|
|
|
<para>This option will result in <command>systemd-run</command> synchronously waiting for
|
|
the transient service to terminate, similar to specifying <option>--wait</option>. If specified
|
|
along with <option>--wait</option>, <command>systemd-run</command> won't exit when manually disconnecting
|
|
from the pseudo TTY device.</para>
|
|
|
|
<para>Note that
|
|
<citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
|
<command>shell</command> command is usually a better alternative for requesting a new, interactive login
|
|
session on the local host or a local container.</para>
|
|
|
|
<para>See below for details on how this switch combines with <option>--pipe</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v219"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--pipe</option></term>
|
|
<term><option>-P</option></term>
|
|
|
|
<listitem><para>If specified, standard input, output, and error of the transient service are inherited from the
|
|
<command>systemd-run</command> command itself. This allows <command>systemd-run</command>
|
|
to be used within shell pipelines.</para>
|
|
|
|
<para>Note that this mode is not suitable for interactive command shells and similar, as the
|
|
service process will not become a TTY controller when invoked on a terminal. Use <option>--pty</option>
|
|
instead in that case.</para>
|
|
|
|
<para>When both <option>--pipe</option> and <option>--pty</option> are used in combination the more appropriate
|
|
option is automatically determined and used. Specifically, when invoked with standard input, output and error
|
|
connected to a TTY <option>--pty</option> is used, and otherwise <option>--pipe</option>.</para>
|
|
|
|
<para>This option will result in <command>systemd-run</command> synchronously waiting for
|
|
the transient service to terminate, similar to specifying <option>--wait</option>.</para>
|
|
|
|
<para>When this option is used the original file descriptors <command>systemd-run</command> receives are passed
|
|
to the service processes as-is. If the service runs with different privileges than
|
|
<command>systemd-run</command>, this means the service might not be able to reopen the passed file
|
|
descriptors, due to normal file descriptor access restrictions. If the invoked process is a shell script that
|
|
uses the <command>echo "hello" >/dev/stderr</command> construct for writing messages to stderr, this might
|
|
cause problems, as this only works if stderr can be reopened. To mitigate this use the construct <command>echo
|
|
"hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v235"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--shell</option></term>
|
|
<term><option>-S</option></term>
|
|
|
|
<listitem><para>A shortcut for <literal>--pty --same-dir --wait --collect --service-type=exec $SHELL</literal>,
|
|
i.e. requests an interactive shell in the current working directory, running in service context, accessible
|
|
with a single switch.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v240"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--quiet</option></term>
|
|
<term><option>-q</option></term>
|
|
|
|
<listitem><para>Suppresses additional informational output
|
|
while running. This is particularly useful in combination with
|
|
<option>--pty</option> when it will suppress the initial
|
|
message explaining how to terminate the TTY connection.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v219"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--on-active=</option></term>
|
|
<term><option>--on-boot=</option></term>
|
|
<term><option>--on-startup=</option></term>
|
|
<term><option>--on-unit-active=</option></term>
|
|
<term><option>--on-unit-inactive=</option></term>
|
|
|
|
<listitem><para>Defines a monotonic timer relative to different starting points for starting the specified
|
|
command. See <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>,
|
|
<varname>OnUnitActiveSec=</varname> and <varname>OnUnitInactiveSec=</varname> in
|
|
<citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
|
details. These options are shortcuts for <command>--timer-property=</command> with the relevant properties.
|
|
These options may not be combined with <option>--scope</option> or <option>--pty</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v218"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--on-calendar=</option></term>
|
|
|
|
<listitem><para>Defines a calendar timer for starting the specified command. See <varname>OnCalendar=</varname>
|
|
in <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
|
|
option is a shortcut for <command>--timer-property=OnCalendar=</command>. This option may not be combined with
|
|
<option>--scope</option> or <option>--pty</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v218"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--on-clock-change</option></term>
|
|
<term><option>--on-timezone-change</option></term>
|
|
|
|
<listitem><para>Defines a trigger based on system clock jumps or timezone changes for starting the
|
|
specified command. See <varname>OnClockChange=</varname> and <varname>OnTimezoneChange=</varname> in
|
|
<citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. These
|
|
options are shortcuts for <command>--timer-property=OnClockChange=yes</command> and
|
|
<command>--timer-property=OnTimezoneChange=yes</command>. These options may not be combined with
|
|
<option>--scope</option> or <option>--pty</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v242"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--path-property=</option></term>
|
|
<term><option>--socket-property=</option></term>
|
|
<term><option>--timer-property=</option></term>
|
|
|
|
<listitem><para>Sets a property on the path, socket, or timer unit that is created. This option is
|
|
similar to <option>--property=</option>, but applies to the transient path, socket, or timer unit
|
|
rather than the transient service unit created. This option takes an assignment in the same format as
|
|
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
|
<command>set-property</command> command. These options may not be combined with
|
|
<option>--scope</option> or <option>--pty</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v218"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--no-block</option></term>
|
|
|
|
<listitem>
|
|
<para>Do not synchronously wait for the unit start operation to finish. If this option is not specified, the
|
|
start request for the transient unit will be verified, enqueued and <command>systemd-run</command> will wait
|
|
until the unit's start-up is completed. By passing this argument, it is only verified and enqueued. This
|
|
option may not be combined with <option>--wait</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v220"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--wait</option></term>
|
|
|
|
<listitem><para>Synchronously wait for the transient service to terminate. If this option is specified, the
|
|
start request for the transient unit is verified, enqueued, and waited for. Subsequently the invoked unit is
|
|
monitored, and it is waited until it is deactivated again (most likely because the specified command
|
|
completed). On exit, terse information about the unit's runtime is shown, including total runtime (as well as
|
|
CPU usage, if <option>--property=CPUAccounting=1</option> was set) and the exit code and status of the main
|
|
process. This output may be suppressed with <option>--quiet</option>. This option may not be combined with
|
|
<option>--no-block</option>, <option>--scope</option> or the various path, socket, or timer options.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v232"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-G</option></term>
|
|
<term><option>--collect</option></term>
|
|
|
|
<listitem><para>Unload the transient unit after it completed, even if it failed. Normally, without this option,
|
|
all units that ran and failed are kept in memory until the user explicitly resets their failure state with
|
|
<command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that ran
|
|
successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more
|
|
aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for
|
|
<command>--property=CollectMode=inactive-or-failed</command>, see the explanation for
|
|
<varname>CollectMode=</varname> in
|
|
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further
|
|
information.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v236"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--ignore-failure</option></term>
|
|
|
|
<listitem><para>By default, if the specified command fails the invoked unit will be marked failed
|
|
(though possibly still unloaded, see <option>--collect=</option>, above), and this is reported in the
|
|
logs. If this switch is specified this is suppressed and any non-success exit status/code of the
|
|
command is treated as success.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--background=<replaceable>COLOR</replaceable></option></term>
|
|
|
|
<listitem><para>Change the terminal background color to the specified ANSI color as long as the
|
|
session lasts. The color specified should be an ANSI X3.64 SGR background color, i.e. strings such as
|
|
<literal>40</literal>, <literal>41</literal>, …, <literal>47</literal>, <literal>48;2;…</literal>,
|
|
<literal>48;5;…</literal>. See <ulink
|
|
url="https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters">ANSI
|
|
Escape Code (Wikipedia)</ulink> for details.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v256"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="user-system-options.xml" xpointer="user" />
|
|
<xi:include href="user-system-options.xml" xpointer="system" />
|
|
<xi:include href="user-system-options.xml" xpointer="host" />
|
|
<xi:include href="user-system-options.xml" xpointer="machine" />
|
|
<xi:include href="user-system-options.xml" xpointer="capsule" />
|
|
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
</variablelist>
|
|
|
|
<para>All command line arguments after the first non-option argument become part of the command line of
|
|
the launched process.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned. If <command>systemd-run</command> failed to start the service, a
|
|
non-zero return value will be returned. If <command>systemd-run</command> waits for the service to
|
|
terminate, the return value will be propagated from the service. 0 will be returned on success, including
|
|
all the cases where systemd considers a service to have exited cleanly, see the discussion of
|
|
<varname>SuccessExitStatus=</varname> in
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
|
|
<example>
|
|
<title>Logging environment variables provided by systemd to services</title>
|
|
|
|
<programlisting># systemd-run env
|
|
Running as unit: run-19945.service
|
|
# journalctl -u run-19945.service
|
|
Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env...
|
|
Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env.
|
|
Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
|
|
Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8
|
|
Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Limiting resources available to a command</title>
|
|
|
|
<programlisting># systemd-run -p IOWeight=10 updatedb</programlisting>
|
|
|
|
<para>This command invokes the <citerefentry
|
|
project='man-pages'><refentrytitle>updatedb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
tool, but lowers the block I/O weight for it to 10. See
|
|
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
for more information on the <varname>IOWeight=</varname> property.</para>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Running commands at a specified time</title>
|
|
|
|
<para>The following command will touch a file after 30 seconds.</para>
|
|
|
|
<programlisting># date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
|
|
Mon Dec 8 20:44:24 KST 2014
|
|
Running as unit: run-71.timer
|
|
Will run service as unit: run-71.service
|
|
# journalctl -b -u run-71.timer
|
|
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
|
|
Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
|
|
Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
|
|
# journalctl -b -u run-71.service
|
|
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
|
|
Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
|
|
Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Allowing access to the tty</title>
|
|
|
|
<para>The following command invokes
|
|
<citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
as a service passing its standard input, output and error to the calling TTY.</para>
|
|
|
|
<programlisting># systemd-run -t --send-sighup bash</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Start <command>screen</command> as a user service</title>
|
|
|
|
<programlisting>$ systemd-run --scope --user screen
|
|
Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope.
|
|
|
|
$ screen -ls
|
|
There is a screen on:
|
|
492..laptop (Detached)
|
|
1 Socket in /var/run/screen/S-fatima.
|
|
</programlisting>
|
|
|
|
<para>This starts the <command>screen</command> process as a child of the
|
|
<command>systemd --user</command> process that was started by
|
|
<filename>user@.service</filename>, in a scope unit. A
|
|
<citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
unit is used instead of a
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
unit, because <command>screen</command> will exit when detaching from the terminal,
|
|
and a service unit would be terminated. Running <command>screen</command>
|
|
as a user unit has the advantage that it is not part of the session scope.
|
|
If <varname>KillUserProcesses=yes</varname> is configured in
|
|
<citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
the default, the session scope will be terminated when the user logs
|
|
out of that session.</para>
|
|
|
|
<para>The <filename>user@.service</filename> is started automatically
|
|
when the user first logs in, and stays around as long as at least one
|
|
login session is open. After the user logs out of the last session,
|
|
<filename>user@.service</filename> and all services underneath it
|
|
are terminated. This behavior is the default, when "lingering" is
|
|
not enabled for that user. Enabling lingering means that
|
|
<filename>user@.service</filename> is started automatically during
|
|
boot, even if the user is not logged in, and that the service is
|
|
not terminated when the user logs out.</para>
|
|
|
|
<para>Enabling lingering allows the user to run processes without being logged in,
|
|
for example to allow <command>screen</command> to persist after the user logs out,
|
|
even if the session scope is terminated. In the default configuration, users can
|
|
enable lingering for themselves:</para>
|
|
|
|
<programlisting>$ loginctl enable-linger</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Variable expansion by the manager</title>
|
|
|
|
<programlisting>$ systemd-run -t echo "<${INVOCATION_ID}>" '<${INVOCATION_ID}>'
|
|
<> <5d0149bfa2c34b79bccb13074001eb20>
|
|
</programlisting>
|
|
|
|
<para>The first argument is expanded by the shell (double quotes), but the second one is not expanded
|
|
by the shell (single quotes).
|
|
<citerefentry project='man-pages'><refentrytitle>echo</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
is called with [<literal>/usr/bin/echo</literal>,
|
|
<literal><></literal>, <literal><${INVOCATION_ID}></literal>] as the argument array, and then
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
generates <varname>${INVOCATION_ID}</varname> and substitutes it in the command-line. This substitution
|
|
could not be done on the client side, because the target ID that will be set for the service isn't
|
|
known before the call is made.</para>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Variable expansion and output redirection using a shell</title>
|
|
|
|
<para>Variable expansion by
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
can be disabled with <varname>--expand-environment=no</varname>.</para>
|
|
|
|
<para>Disabling variable expansion can be useful if the command to execute contains dollar characters
|
|
and escaping them would be inconvenient. For example, when a shell is used:</para>
|
|
|
|
<programlisting>$ systemd-run --expand-environment=no -t bash \
|
|
-c 'echo $SHELL $$ >/dev/stdout'
|
|
/bin/bash 12345
|
|
</programlisting>
|
|
|
|
<para>The last argument is passed verbatim to the
|
|
<citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
shell which is started by the service unit. The shell expands <literal>$SHELL</literal> to the path of
|
|
the shell, and <literal>$$</literal> to its process number, and then those strings are passed to the
|
|
<command>echo</command> built-in and printed to standard output (which in this case is connected to the
|
|
calling terminal).</para>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Return value</title>
|
|
|
|
<programlisting>$ systemd-run --user --wait true
|
|
$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11'
|
|
$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 --expand-environment=no \
|
|
bash -c 'kill -SIGUSR1 $$'</programlisting>
|
|
|
|
<para>Those three invocations will succeed, i.e. terminate with an exit code of 0.</para>
|
|
</example>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para><simplelist type="inline">
|
|
<member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>run0</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
</simplelist></para>
|
|
</refsect1>
|
|
|
|
</refentry>
|