Merge pull request #10797 from poettering/run-generator

add new "systemd-run-generator" for running arbitrary commands from the kernel command line as system services using the "systemd.run=" kernel command line switch

4 files changed, 114 insertions, 4 deletions

diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index 43b3a3667..7e4b51eb9 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -92,6 +92,17 @@
       </varlistentry>
 
       <varlistentry>
+        <term><varname>systemd.run=</varname></term>
+        <term><varname>systemd.run_success_action=</varname></term>
+        <term><varname>systemd.run_failure_action=</varname></term>
+        <listitem>
+          <para>Additional parameters understood by
+          <citerefentry><refentrytitle>systemd-run-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, to
+          run a command line specified on the kernel command line as system service after booting up.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><varname>systemd.early_core_pattern=</varname></term>
         <listitem>
           <para>During early boot, the generation of core dump files is disabled until a core dump handler (if any)
diff --git a/man/rules/meson.build b/man/rules/meson.build
index b93ed9971..b09185982 100644
--- a/man/rules/meson.build
+++ b/man/rules/meson.build
@@ -737,6 +737,7 @@ manpages = [
   '8',
   ['systemd-rfkill', 'systemd-rfkill.socket'],
   'ENABLE_RFKILL'],
+ ['systemd-run-generator', '8', [], ''],
  ['systemd-run', '1', [], ''],
  ['systemd-sleep.conf', '5', ['sleep.conf.d'], ''],
  ['systemd-socket-activate', '1', [], ''],
diff --git a/man/systemd-run-generator.xml b/man/systemd-run-generator.xml
new file mode 100644
index 000000000..20eb6916e
--- /dev/null
+++ b/man/systemd-run-generator.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!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+
+-->
+<refentry id="systemd-run-generator">
+
+  <refentryinfo>
+    <title>systemd-run-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-run-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-run-generator</refname>
+    <refpurpose>Generator for invoking commands specified on the kernel command line as system service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-run-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-run-generator</filename> is a generator
+    that reads the kernel command line and understands three
+    options:</para>
+
+    <para>If the <option>systemd.run=</option> option is specified and followed by a command line, a unit named
+    <filename>kernel-command-line.service</filename> is generated for it and booted into. The service has
+    <varname>Type=oneshot</varname> set, and has <varname>SuccessAction=exit</varname> and
+    <varname>FailureAction=exit</varname> configured by default, thus ensuring that the system is shut down as soon as
+    the command completes. The exit status of the command line is propagated to the invoking container manager, if
+    this applies (which might propagate this further, to the calling shell — e.g.
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry> does this). If
+    this option is used multiple times the unit file will contain multiple <varname>ExecStart=</varname> lines, to
+    execute all commands in order. The command is started as regular service, i.e. with
+    <varname>DefaultDependencies=</varname> on. </para>
+
+    <para>Use <option>systemd.run_success_action=</option> and <option>systemd.run_failure_action=</option> to tweak
+    how to react to the process completing. In particular assigning <literal>none</literal> will leave the system
+    running after the command completes. For further details on supported arguments, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para><filename>systemd-run-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Use a command like the following to add a user to the user database inside a container run with
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry>:</para>
+
+    <programlisting># systemd-nspawn -D mycontainer -b systemd.run='"adduser test"'</programlisting>
+    <para>(Note the requirement for double quoting in the command line above. The first level of quoting ('') is
+    processed and removed by the command shell used to invoke <command>systemd-nspawn</command>. The second level of
+    quoting ("") is propagated to the kernel command line of the container and processed and removed by
+    <command>systemd-run-generator</command>. Both together make sure both words of the specified command line
+    <command>adduser test</command> end up in the generated unit file together and are neither split apart by the
+    command shell nor by the generator.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index be77e7229..2c66db854 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -887,10 +887,26 @@
         cause no dirty file systems on reboot (i.e. equivalent to <command>systemctl reboot -f</command>) and
         <option>reboot-immediate</option> causes immediate execution of the
         <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, which
-        might result in data loss. Similarly, <option>poweroff</option>, <option>poweroff-force</option>,
-        <option>poweroff-immediate</option> have the effect of powering down the system with similar
-        semantics. <option>exit</option> causes the manager to exit following the normal shutdown procedure, and
-        <option>exit-force</option> causes it terminate without shutting down services.</para></listitem>
+        might result in data loss (i.e. equivalent to <command>systemctl reboot -ff</command>). Similarly,
+        <option>poweroff</option>, <option>poweroff-force</option>, <option>poweroff-immediate</option> have the effect
+        of powering down the system with similar semantics. <option>exit</option> causes the manager to exit following
+        the normal shutdown procedure, and <option>exit-force</option> causes it terminate without shutting down
+        services. When <option>exit</option> or <option>exit-force</option> is used by default the exit status of the
+        main process of the unit (if this applies) is returned from the service manager. However, this may be overriden
+        with <varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FailureActionExitStatus=</varname></term>
+        <term><varname>SuccessActionExitStatus=</varname></term>
+
+        <listitem><para>Controls the exit status to propagate back to an invoking container manager (in case of a
+        system service) or service manager (in case of a user manager) when the
+        <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> are set to <option>exit</option> or
+        <option>exit-force</option> and the action is triggered. By default the exit status of the main process of the
+        triggering unit (if this applies) is propagated. Takes a value in the range 0…255 or the empty string to
+        request default behaviour.</para></listitem>
       </varlistentry>
 
       <varlistentry>