-<?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">
-
-<!--
- SPDX-License-Identifier: LGPL-2.1+
--->
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="systemd-run"
xmlns:xi="http://www.w3.org/2001/XInclude">
<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>
</refsect1>
<refsect1>
<varlistentry>
<term><option>--unit=</option></term>
+ <term><option>-u</option></term>
<listitem><para>Use this unit name instead of an automatically
generated one.</para></listitem>
<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>.</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> (when running in
+ <option>--system</option> mode) or the root slice (when running in <option>--user</option>
+ mode).</para>
+ </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 inherited slice. This option can be combined with <option>--slice=</option>.</para>
+
+ <para>An inherited slice is located within <command>systemd-run</command> slice. Example: if
+ <command>systemd-run</command> slice is <filename>foo.slice</filename>, and the
+ <option>--slice=</option> argument is <filename>bar</filename>, the unit will be placed under the
+ <filename>foo-bar.slice</filename>.</para>
+
</listitem>
</varlistentry>
</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>
+ </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></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>
"hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para></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></listitem>
+ </varlistentry>
+
<varlistentry>
<term><option>--quiet</option></term>
<term><option>-q</option></term>
</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></listitem>
+ </varlistentry>
+
<varlistentry>
<term><option>--path-property=</option></term>
<term><option>--socket-property=</option></term>
<refsect1>
<title>Exit status</title>
- <para>On success, 0 is returned, a non-zero failure
- code otherwise.</para>
+ <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>
<programlisting>$ loginctl enable-linger</programlisting>
</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 bash -c 'kill -SIGUSR1 $$$$'</programlisting>
+
+ <para>Those three invocations will succeed, i.e. terminate with an exit code of 0.</para>
+ </example>
</refsect1>
<refsect1>