конфигурация блока розеток (Socket unit configuration)
Описание (Description)
A unit configuration file whose name ends in ".socket" encodes
information about an IPC or network socket or a file system FIFO
controlled and supervised by systemd, for socket-based
activation.
This man page lists the configuration options specific to this
unit type. See systemd.unit(5) for the common options of all unit
configuration files. The common configuration items are
configured in the generic [Unit] and [Install] sections. The
socket specific configuration options are configured in the
[Socket] section.
Additional options are listed in systemd.exec(5), which define
the execution environment the ExecStartPre=, ExecStartPost=,
ExecStopPre= and ExecStopPost= commands are executed in, and in
systemd.kill(5), which define the way the processes are
terminated, and in systemd.resource-control(5), which configure
resource control settings for the processes of the socket.
For each socket unit, a matching service unit must exist,
describing the service to start on incoming traffic on the socket
(see systemd.service(5) for more information about .service
units). The name of the .service unit is by default the same as
the name of the .socket unit, but can be altered with the
Service= option described below. Depending on the setting of the
Accept= option described below, this .service unit must either be
named like the .socket unit, but with the suffix replaced, unless
overridden with Service=; or it must be a template unit named the
same way. Example: a socket file foo.socket needs a matching
service foo.service if Accept=no is set. If Accept=yes is set, a
service template foo@.service must exist from which services are
instantiated for each incoming connection.
No implicit WantedBy= or RequiredBy= dependency from the socket
to the service is added. This means that the service may be
started without the socket, in which case it must be able to open
sockets by itself. To prevent this, an explicit Requires=
dependency may be added.
Socket units may be used to implement on-demand starting of
services, as well as parallelized starting of services. See the
blog stories linked at the end for an introduction.
Note that the daemon software configured for socket activation
with socket units needs to be able to accept sockets from
systemd, either via systemd's native socket passing interface
(see sd_listen_fds(3) for details about the precise protocol used
and the order in which the file descriptors are passed) or via
traditional inetd(8)-style socket passing (i.e. sockets passed in
via standard input and output, using StandardInput=socket in the
service file).
All network sockets allocated through .socket units are allocated
in the host's network namespace (see network_namespaces(7)). This
does not mean however that the service activated by a configured
socket unit has to be part of the host's network namespace as
well. It is supported and even good practice to run services in
their own network namespace (for example through PrivateNetwork=,
see systemd.exec(5)), receiving only the sockets configured
through socket-activation from the host's namespace. In such a
set-up communication within the host's network namespace is only
permitted through the activation sockets passed in while all
sockets allocated from the service code itself will be associated
with the service's own namespace, and thus possibly subject to a
restrictive configuration.
