<para>The <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
command allows creating <filename>.service</filename> and <filename>.scope</filename> units dynamically
and transiently from the command line.</para>
-
- <para>In addition to the various drop-in behaviors described in
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- services also support a top-level drop-in with <filename>-.service.d/</filename> that allows
- altering or adding to the settings of all services on the system.
- The formatting and precedence of applying drop-in configurations follow what is defined in
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- However, configurations in <filename>-.service.d/</filename> have the lowest precedence compared to settings
- in the service specific override directories. For example, for <filename>foo-bar-baz.service</filename>,
- drop-ins in <filename>foo-bar-baz.service.d/</filename> override the ones in
- <filename>foo-bar-.service.d/</filename>, which override the ones <filename>foo-.service.d/</filename>,
- which override the ones in <filename>-.service.d/</filename>.
- </para>
</refsect1>
<refsect1>
this notification message has been sent. If this option is used, <varname>NotifyAccess=</varname> (see
below) should be set to open access to the notification socket provided by systemd. If
<varname>NotifyAccess=</varname> is missing or set to <option>none</option>, it will be forcibly set to
- <option>main</option>. Note that currently <varname>Type=</varname><option>notify</option> will not work if
- used in combination with <varname>PrivateNetwork=</varname><option>yes</option>.</para></listitem>
+ <option>main</option></para></listitem>.
<listitem><para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however,
actual execution of the service program is delayed until all active jobs are dispatched. This may be used
<varname>ExecStart=</varname>, or <varname>ExecStartPost=</varname> fail (and are not prefixed with
<literal>-</literal>, see above) or time out before the service is fully up, execution continues with commands
specified in <varname>ExecStopPost=</varname>, the commands in <varname>ExecStop=</varname> are skipped.</para>
+
+ <para>Note that the execution of <varname>ExecStartPost=</varname> is taken into account for the purpose of
+ <varname>Before=</varname>/<varname>After=</varname> ordering constraints.</para>
</listitem>
</varlistentry>
service, as well as the main process' exit code and status, set in the <varname>$SERVICE_RESULT</varname>,
<varname>$EXIT_CODE</varname> and <varname>$EXIT_STATUS</varname> environment variables, see
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
- details.</para></listitem>
+ details.</para>
+
+ <para>Note that the execution of <varname>ExecStopPost=</varname> is taken into account for the purpose of
+ <varname>Before=</varname>/<varname>After=</varname> ordering constraints.</para></listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><varname>TimeoutStopSec=</varname></term>
<listitem><para>This option serves two purposes. First, it configures the time to wait for each
- <constant>ExecStop=</constant> command. If any of them times out, subsequent <constant>ExecStop=</constant> commands
- are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <constant>ExecStop=</constant>
+ <varname>ExecStop=</varname> command. If any of them times out, subsequent <varname>ExecStop=</varname> commands
+ are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <varname>ExecStop=</varname>
commands are specified, the service gets the <constant>SIGTERM</constant> immediately. Second, it configures the time
to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated
by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in
effect.</para>
<example>
- <title>A service with with the the <varname>SuccessExitStatus=</varname> setting</title>
+ <title>A service with with the <varname>SuccessExitStatus=</varname> setting</title>
<programlisting>SuccessExitStatus=TEMPFAIL 250 SIGUSR1</programlisting>
<para>Basic environment variable substitution is supported. Use
<literal>${FOO}</literal> as part of a word, or as a word of its
- own, on the command line, in which case it will be replaced by the
- value of the environment variable including all whitespace it
- contains, resulting in a single argument. Use
- <literal>$FOO</literal> as a separate word on the command line, in
+ own, on the command line, in which case it will be erased and replaced
+ by the exact value of the environment variable (if any) including all
+ whitespace it contains, always resulting in exactly a single argument.
+ Use <literal>$FOO</literal> as a separate word on the command line, in
which case it will be replaced by the value of the environment
variable split at whitespace, resulting in zero or more arguments.
For this type of expansion, quotes are respected when splitting
<para><varname>Type=</varname><option>oneshot</option> are the
only service units that may have more than one
<varname>ExecStart=</varname> specified. For units with multiple
- commands (<varname noindex="true">Type=oneshot</varname>), all commands will be run again.</para>
- <para> For <varname noindex="true">Type=oneshot</varname>, <varname>Restart=</varname><option>always</option>
+ commands (<varname index="false">Type=oneshot</varname>), all commands will be run again.</para>
+ <para> For <varname index="false">Type=oneshot</varname>, <varname>Restart=</varname><option>always</option>
and <varname>Restart=</varname><option>on-success</option> are <emphasis>not</emphasis> allowed.</para>
</example>
projects / thirdparty / systemd.git / blobdiff