From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date: Mon, 22 Aug 2022 11:37:13 +0000 (+0200)
Subject: man/run: we accept relative paths for run
X-Git-Tag: v252-rc1~346^2~1
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=6a6707ce8589fb5074a33ccbe6fdbd476e8b7021;p=thirdparty%2Fsystemd.git

man/run: we accept relative paths for run

I think this is a left-over from before we changed ExecStart= to allow
non-absolute paths, *and* changed systemd-run itself to resolve paths too.
---

diff --git a/man/systemd-run.xml b/man/systemd-run.xml
index faf88d560a7..59105654275 100644
--- a/man/systemd-run.xml
+++ b/man/systemd-run.xml
@@ -72,7 +72,7 @@
     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>
+    (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
@@ -82,15 +82,16 @@
     <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
+    <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>
+    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>
@@ -411,10 +412,8 @@
       <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. If a command is run as service unit, the first argument
-    needs to be an absolute program path.</para>
+    <para>All command line arguments after the first non-option argument become part of the command line of
+    the launched process.</para>
   </refsect1>
 
   <refsect1>