<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
<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,
<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>
<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>
<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>
<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
<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>
<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>,
<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>
<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
projects / thirdparty / systemd.git / commitdiff
