picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

man: generalize "binary" to "program" (#7668) 

Systemd services are permitted to be scripts, as well as binary
executables.

The same also applies to the underlying /sbin/mount and /sbin/swapon.
It is not necessary for the user to consider what type of program file
these are.  Nor is it necessary with systemd-nspawn, to distinguish between
init as a "binary" v.s. a user-specified "program".

Also fix a couple of grammar nits in the modified sentences.
This commit is contained in:
Alan Jenkins 2017-12-16 10:48:12 +00:00 committed by Zbigniew Jędrzejewski-Szmek
parent 6671e818e9
commit 3f2d136505
6 changed files with 18 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
man/systemd-nspawn.xml
View File

@ -149,7 +149,7 @@
<title>Options</title>
<para>If option <option>-b</option> is specified, the arguments
are used as arguments for the init binary. Otherwise,
are used as arguments for the init program. Otherwise,
<replaceable>COMMAND</replaceable> specifies the program to launch
in the container, and the remaining arguments are used as
arguments for this program. If <option>--boot</option> is not used and
@ -273,12 +273,12 @@
<term><option>--as-pid2</option></term>
<listitem><para>Invoke the shell or specified program as process ID (PID) 2 instead of PID 1 (init). By
default, if neither this option nor <option>--boot</option> is used, the selected binary is run as process with
PID 1, a mode only suitable for programs that are aware of the special semantics that the process with PID 1
has on UNIX. For example, it needs to reap all processes reparented to it, and should implement
default, if neither this option nor <option>--boot</option> is used, the selected program is run as the process
with PID 1, a mode only suitable for programs that are aware of the special semantics that the process with
PID 1 has on UNIX. For example, it needs to reap all processes reparented to it, and should implement
<command>sysvinit</command> compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute
on SIGTERM, reload configuration on SIGHUP, and so on). With <option>--as-pid2</option> a minimal stub init
process is run as PID 1 and the selected binary is executed as PID 2 (and hence does not need to implement any
process is run as PID 1 and the selected program is executed as PID 2 (and hence does not need to implement any
special semantics). The stub init process will reap processes as necessary and react appropriately to
signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been
modified to run correctly as PID 1. Or in other words: this switch should be used for pretty much all commands,
@ -291,9 +291,9 @@
<term><option>-b</option></term>
<term><option>--boot</option></term>
<listitem><para>Automatically search for an init binary and invoke it as PID 1, instead of a shell or a user
<listitem><para>Automatically search for an init program and invoke it as PID 1, instead of a shell or a user
supplied program. If this option is used, arguments specified on the command line are used as arguments for the
init binary. This option may not be combined with <option>--as-pid2</option>.</para>
init program. This option may not be combined with <option>--as-pid2</option>.</para>
<para>The following table explains the different modes of invocation and relationship to
<option>--as-pid2</option> (see above):</para>
@ -322,7 +322,7 @@
<row>
<entry><option>--boot</option> specified</entry>
<entry>An init binary as automatically searched and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process.</entry>
<entry>An init program is automatically searched for and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process.</entry>
</row>
</tbody>

4
man/systemd-run.xml
View File

@ -352,8 +352,8 @@
<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, its first argument
needs to be an absolute binary path.</para>
process. If a command is run as service unit, the first argument
needs to be an absolute program path.</para>
</refsect1>
<refsect1>

7
man/systemd-socket-activate.xml
View File

@ -62,8 +62,9 @@
<refsect1>
<title>Description</title>
<para><command>systemd-socket-activate</command> may be used to launch a socket-activated service binary from the command
line for testing purposes. It may also be used to launch individual instances of the service binary per connection.
<para><command>systemd-socket-activate</command> may be used to launch a socket-activated service program from the
command line for testing purposes. It may also be used to launch individual instances of the service program per
connection.
</para>
<para>The daemon to launch and its options should be specified
@ -97,7 +98,7 @@
<term><option>-a</option></term>
<term><option>--accept</option></term>
<listitem><para>Launch an instance of the service binary for each connection and pass the connection
<listitem><para>Launch an instance of the service program for each connection and pass the connection
socket.</para></listitem>
</varlistentry>

2
man/systemd.mount.xml
View File

@ -71,7 +71,7 @@
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
which define the execution environment the
<citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
binary is executed in, and in
program is executed in, and in
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
which define the way the processes are terminated, and in
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

4
man/systemd.service.xml
View File

@ -228,10 +228,10 @@
<varname>PrivateNetwork=</varname><option>yes</option>.</para>
<para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however, actual execution
of the service binary is delayed until all active jobs are dispatched. This may be used to avoid interleaving
of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving
of output of shell services with the status output on the console. Note that this type is useful only to
improve console output, it is not useful as a general unit ordering tool, and the effect of this service type
is subject to a 5s time-out, after which the service binary is invoked anyway.</para>
is subject to a 5s time-out, after which the service program is invoked anyway.</para>
</listitem>
</varlistentry>

2
man/systemd.swap.xml
View File

@ -72,7 +72,7 @@
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
which define the execution environment the <citerefentry
project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
binary is executed in, in
program is executed in, in
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
which define the way these processes are
terminated, and in