"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
+ SPDX-License-Identifier: LGPL-2.1+
+
This file is part of systemd.
Copyright 2013 Zbigniew Jędrzejewski-Szmek
<refnamediv>
<refname>systemd-run</refname>
- <refpurpose>Run programs in transient scope or service or timer units</refpurpose>
+ <refpurpose>Run programs in transient scope units, service units, or timer-scheduled service units</refpurpose>
</refnamediv>
<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 transient <filename>.timer</filename>
- units.</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.</para>
-
- <para>If a command is run as transient scope unit, it will be
- started 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 similar 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 timer options such as
- <option>--on-calendar=</option> (see below), a transient timer
- unit is created alongside the service unit for the specified
- command. Only the transient timer unit is started immediately, the
- transient service unit will be started when the transient timer
- elapses. If the <option>--unit=</option> is specified, the
- <replaceable>COMMAND</replaceable> may be omitted. In this case,
- <command>systemd-run</command> only creates a
- <filename>.timer</filename> unit that invokes the specified unit
- when elapsing.</para>
+ <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>.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> or <option>--wait</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 similar 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 timer options such as <option>--on-calendar=</option> (see below), a transient timer
+ unit is created alongside the service unit for the specified command. Only the transient timer unit is started
+ immediately, the transient service unit will be started when the timer elapses. 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>.timer</filename> unit that invokes the specified unit when
+ elapsing.</para>
</refsect1>
<refsect1>
<term><option>--scope</option></term>
<listitem>
- <para>Create a transient <filename>.scope</filename> unit instead of
- the default transient <filename>.service</filename> unit.
+ <para>Create a transient <filename>.scope</filename> unit instead of the default transient
+ <filename>.service</filename> unit (see above).
</para>
</listitem>
</varlistentry>
<term><option>--property=</option></term>
<term><option>-p</option></term>
- <listitem><para>Sets a unit property for the scope or service
- unit that is created. This takes an assignment in the same
- format as
+ <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>
</listitem>
<varlistentry>
<term><option>--description=</option></term>
- <listitem><para>Provide a description for the service or scope
- unit. If not specified, the command itself will be used as a
- description. See <varname>Description=</varname> in
+ <listitem><para>Provide a description for the service, scope 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></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 the <filename>system.slice</filename>.</para>
+ <listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part of the
+ specified slice, instead of <filename>system.slice</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--remain-after-exit</option></term>
- <listitem><para>After the service or scope 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
+ <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>
<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
+ <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>
<term><option>--uid=</option></term>
<term><option>--gid=</option></term>
- <listitem><para>Runs the service process under the UNIX user
- and group. Also see <varname>User=</varname> and
- <varname>Group=</varname> in
+ <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>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
- <term><option>--setenv=</option></term>
+ <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 variables set. Also see
- <varname>Environment=</varname> in
+ <listitem><para>Runs the service process with the specified environment variable set.
+ Also see <varname>Environment=</varname> in
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
</listitem>
</varlistentry>
<term><option>--pty</option></term>
<term><option>-t</option></term>
- <listitem><para>When invoking a command, the service connects
- its standard input and output to the invoking tty via a
- pseudo TTY device. This allows invoking binaries as services
- that expect interactive user input, such as interactive
- command shells.</para></listitem>
+ <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>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></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.
+ 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>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 re-open 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 re-opened. To mitigate this use the construct <command>echo
+ "hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--on-unit-active=</option></term>
<term><option>--on-unit-inactive=</option></term>
- <listitem><para>Defines monotonic timers relative to different
- starting points. Also 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>. This
- options have no effect in conjunction with
- <option>--scope</option>.</para>
+ <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 may not be combined with <option>--scope</option> or <option>--pty</option>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--on-calendar=</option></term>
- <listitem><para>Defines realtime (i.e. wallclock) timers with
- calendar event expressions. Also see
- <varname>OnCalendar=</varname> in
- <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
- option has no effect in conjunction with
- <option>--scope</option>.</para>
+ <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 may not be combined with <option>--scope</option> or <option>--pty</option>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--timer-property=</option></term>
- <listitem><para>Sets a timer unit property for the timer unit
- that is created. It is similar with
- <option>--property</option> but only for created timer
- unit. This option only has effect in conjunction with
- <option>--on-active=</option>, <option>--on-boot=</option>,
- <option>--on-startup=</option>,
- <option>--on-unit-active=</option>,
- <option>--on-unit-inactive=</option>,
- <option>--on-calendar=</option>. This takes an assignment in
- the same format as
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+ <listitem><para>Sets a property on the timer unit that is created. This option is similar to
+ <option>--property=</option> but applies to the transient timer unit rather than the transient service unit
+ created. This option only has an effect in conjunction with <option>--on-active=</option>,
+ <option>--on-boot=</option>, <option>--on-startup=</option>, <option>--on-unit-active=</option>,
+ <option>--on-unit-inactive=</option> or <option>--on-calendar=</option>. 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> </listitem>
</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>systemd-run</command> will
- wait until the unit's start-up is completed. By passing this
- argument, it is only verified and enqueued.</para>
+ <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>
</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 timer options.</para></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></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" />
<refsect1>
<title>Examples</title>
- <para>The following command will log the environment variables
- provided by systemd to services:</para>
+ <example>
+ <title>Logging environment variables provided by systemd to services</title>
- <programlisting># systemd-run env
-Running as unit run-19945.service.
+
<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>
- <para>The following 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>BlockIOWeight=</varname>
- property.</para>
+ <example>
+ <title>Limiting resources available to a command</title>
- <programlisting># systemd-run -p BlockIOWeight=10 updatedb</programlisting>
+
<programlisting># systemd-run -p BlockIOWeight=10 updatedb</programlisting>
- <para>The following command will touch a file after 30 seconds.</para>
+ <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>BlockIOWeight=</varname>
+ property.</para>
+ </example>
- <programlisting># date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
+ <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 as unit run-71.service.
+Running as unit: run-71.timer
+Will run service as unit: run-71.service
# journalctl -b -u run-71.timer
-- Logs begin at Fri 2014-12-05 19:09:21 KST, end at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
-- Logs begin at Fri 2014-12-05 19:09:21 KST, end 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>
-
- <para>The following command invokes <filename>/bin/bash</filename>
- as a service passing its standard input, output and error to
- the calling TTY.</para>
-
- <programlisting># systemd-run -t --send-sighup /bin/bash</programlisting>
-
+ </example>
+
+ <example>
+ <title>Allowing access to the tty</title>
+
+ <para>The following command invokes <filename>/bin/bash</filename> as a service
+ passing its standard input, output and error to the calling TTY.</para>
+
+ <programlisting># systemd-run -t --send-sighup /bin/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>
</refsect1>
<refsect1>
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
</para>
</refsect1>
projects / thirdparty / systemd.git / blobdiff