mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-01-08 21:17:47 +03:00
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:
parent
6671e818e9
commit
3f2d136505
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>,
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user