mirror of
https://github.com/systemd/systemd
synced 2024-09-06 08:46:19 +00:00
![Matthieu Baerts (NGI0)](/assets/img/avatar_default.png)
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension that enables a TCP connection to use different paths. It allows a device to make use of multiple interfaces at once to send and receive TCP packets over a single MPTCP connection. MPTCP can aggregate the bandwidth of multiple interfaces or prefer the one with the lowest latency, it also allows a fail-over if one path is down, and the traffic is seamlessly re-injected on other paths. To benefit from MPTCP, both the client and the server have to support it. Multipath TCP is a backward-compatible TCP extension that is enabled by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...). Multipath TCP is included in the Linux kernel since version 5.6 [2]. To use it on Linux, an application must explicitly enable it when creating the socket: int sd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP); No need to change anything else in the application. This patch allows MPTCP protocol in the Socket unit configuration. So now, a <unit>.socket can contain this to use MPTCP instead of TCP: [Socket] SocketProtocol=mptcp MPTCP support has been allowed similarly to what has been already done to allow SCTP: just one line in core/socket.c, a very simple addition thanks to the flexible architecture already in place. On top of that, IPPROTO_MPTCP has also been added in the list of allowed protocols in two other places, and in the doc. It has also been added to the missing_network.h file, for systems with an old libc -- note that it was also required to include <netinet/in.h> in this file to avoid redefinition errors. Link: https://www.rfc-editor.org/rfc/rfc8684.html [1] Link: https://www.mptcp.dev [2]
973 lines
54 KiB
XML
973 lines
54 KiB
XML
<?xml version='1.0'?>
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
|
|
<refentry id="systemd.socket" xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
<refentryinfo>
|
|
<title>systemd.socket</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd.socket</refentrytitle>
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd.socket</refname>
|
|
<refpurpose>Socket unit configuration</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<para><filename><replaceable>socket</replaceable>.socket</filename></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>A unit configuration file whose name ends in
|
|
<literal>.socket</literal> encodes information about an IPC or
|
|
network socket or a file system FIFO controlled and supervised by
|
|
systemd, for socket-based activation.</para>
|
|
|
|
<para>This man page lists the configuration options specific to
|
|
this unit type. See
|
|
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
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.</para>
|
|
|
|
<para>Additional options are listed in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
which define the execution environment the
|
|
<option>ExecStartPre=</option>, <option>ExecStartPost=</option>,
|
|
<option>ExecStopPre=</option> and <option>ExecStopPost=</option>
|
|
commands are 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>,
|
|
which configure resource control settings for the processes of the
|
|
socket.</para>
|
|
|
|
<para>For each socket unit, a matching service unit must exist,
|
|
describing the service to start on incoming traffic on the socket
|
|
(see
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
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 <option>Service=</option> option
|
|
described below. Depending on the setting of the
|
|
<option>Accept=</option> option described below, this .service
|
|
unit must either be named like the .socket unit, but with the
|
|
suffix replaced, unless overridden with <option>Service=</option>;
|
|
or it must be a template unit named the same way. Example: a
|
|
socket file <filename>foo.socket</filename> needs a matching
|
|
service <filename>foo.service</filename> if
|
|
<option>Accept=no</option> is set. If
|
|
<option>Accept=yes</option> is set, a service template
|
|
<filename>foo@.service</filename> must exist from which services
|
|
are instantiated for each incoming connection.</para>
|
|
|
|
<para>No implicit <varname>WantedBy=</varname> or
|
|
<varname>RequiredBy=</varname> 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
|
|
<varname>Requires=</varname> dependency may be added.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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
|
|
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
|
|
details about the precise protocol used and the order in which the file descriptors are passed) or via
|
|
traditional <citerefentry
|
|
project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>-style
|
|
socket passing (i.e. sockets passed in via standard input and output, using
|
|
<varname>StandardInput=socket</varname> in the service file).</para>
|
|
|
|
<para>All network sockets allocated through <filename>.socket</filename> units are allocated in the host's network
|
|
namespace (see <citerefentry
|
|
project='man-pages'><refentrytitle>network_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>). 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 <varname>PrivateNetwork=</varname>, see
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>), 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.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Automatic Dependencies</title>
|
|
|
|
<refsect2>
|
|
<title>Implicit Dependencies</title>
|
|
|
|
<para>The following dependencies are implicitly added:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Socket units automatically gain a <varname>Before=</varname>
|
|
dependency on the service units they activate.</para></listitem>
|
|
|
|
<listitem><para>Socket units referring to file system paths (such as <constant>AF_UNIX</constant>
|
|
sockets or FIFOs) implicitly gain <varname>Requires=</varname> and <varname>After=</varname>
|
|
dependencies on all mount units necessary to access those paths.</para></listitem>
|
|
|
|
<listitem><para>Socket units using the <varname>BindToDevice=</varname>
|
|
setting automatically gain a <varname>BindsTo=</varname> and
|
|
<varname>After=</varname> dependency on the device unit
|
|
encapsulating the specified network interface.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Additional implicit dependencies may be added as result of
|
|
execution and resource control parameters as documented in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
and
|
|
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Default Dependencies</title>
|
|
|
|
<para>The following dependencies are added unless
|
|
<varname>DefaultDependencies=no</varname> is set:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Socket units automatically gain a
|
|
<varname>Before=</varname> dependency on
|
|
<filename>sockets.target</filename>.</para></listitem>
|
|
|
|
<listitem><para>Socket units automatically gain a pair of
|
|
<varname>After=</varname> and <varname>Requires=</varname>
|
|
dependency on <filename>sysinit.target</filename>, and a pair of
|
|
<varname>Before=</varname> and <varname>Conflicts=</varname>
|
|
dependencies on <filename>shutdown.target</filename>. These
|
|
dependencies ensure that the socket unit is started before normal
|
|
services at boot, and is stopped on shutdown. Only sockets
|
|
involved with early boot or late system shutdown should disable
|
|
<varname>DefaultDependencies=</varname> option.</para></listitem>
|
|
</itemizedlist>
|
|
</refsect2>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>Socket unit files may include [Unit] and [Install] sections, which are described in
|
|
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
|
|
<para>Socket unit files must include a [Socket] section, which carries
|
|
information about the socket or FIFO it supervises. A number of
|
|
options that may be used in this section are shared with other
|
|
unit types. These options are documented in
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
|
|
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
The options specific to the [Socket] section of socket units are
|
|
the following:</para>
|
|
|
|
<variablelist class='unit-directives'>
|
|
<varlistentry>
|
|
<term><varname>ListenStream=</varname></term>
|
|
<term><varname>ListenDatagram=</varname></term>
|
|
<term><varname>ListenSequentialPacket=</varname></term>
|
|
<listitem><para>Specifies an address to listen on for a stream
|
|
(<constant>SOCK_STREAM</constant>), datagram
|
|
(<constant>SOCK_DGRAM</constant>), or sequential packet
|
|
(<constant>SOCK_SEQPACKET</constant>) socket, respectively.
|
|
The address can be written in various formats:</para>
|
|
|
|
<para>If the address starts with a slash
|
|
(<literal>/</literal>), it is read as file system socket in
|
|
the <constant>AF_UNIX</constant> socket family.</para>
|
|
|
|
<para>If the address starts with an at symbol
|
|
(<literal>@</literal>), it is read as abstract namespace
|
|
socket in the <constant>AF_UNIX</constant> family. The
|
|
<literal>@</literal> is replaced with a
|
|
<constant>NUL</constant> character before binding. For
|
|
details, see
|
|
<citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
|
|
|
|
<para>If the address string is a single number, it is read as
|
|
port number to listen on via IPv6. Depending on the value of
|
|
<varname>BindIPv6Only=</varname> (see below) this might result
|
|
in the service being available via both IPv6 and IPv4
|
|
(default) or just via IPv6.
|
|
</para>
|
|
|
|
<para>If the address string is a string in the format
|
|
<literal><replaceable>v.w.x.y</replaceable>:<replaceable>z</replaceable></literal>, it is interpreted
|
|
as IPv4 address <replaceable>v.w.x.y</replaceable> and port <replaceable>z</replaceable>.</para>
|
|
|
|
<para>If the address string is a string in the format
|
|
<literal>[<replaceable>x</replaceable>]:<replaceable>y</replaceable></literal>, it is interpreted as
|
|
IPv6 address <replaceable>x</replaceable> and port <replaceable>y</replaceable>. An optional
|
|
interface scope (interface name or number) may be specified after a <literal>%</literal> symbol:
|
|
<literal>[<replaceable>x</replaceable>]:<replaceable>y</replaceable>%<replaceable>dev</replaceable></literal>.
|
|
Interface scopes are only useful with link-local addresses, because the kernel ignores them in other
|
|
cases. Note that if an address is specified as IPv6, it might still make the service available via
|
|
IPv4 too, depending on the <varname>BindIPv6Only=</varname> setting (see below).</para>
|
|
|
|
<para>If the address string is a string in the format
|
|
<literal>vsock:<replaceable>x</replaceable>:<replaceable>y</replaceable></literal>, it is read as CID
|
|
<replaceable>x</replaceable> on a port <replaceable>y</replaceable> address in the
|
|
<constant>AF_VSOCK</constant> family. The CID is a unique 32-bit integer identifier in
|
|
<constant>AF_VSOCK</constant> analogous to an IP address. Specifying the CID is optional, and may be
|
|
set to the empty string. <literal>vsock</literal> may be replaced with
|
|
<literal>vsock-stream</literal>, <literal>vsock-dgram</literal> or <literal>vsock-seqpacket</literal>
|
|
to force usage of the corresponding socket type.</para>
|
|
|
|
<para>Note that <constant>SOCK_SEQPACKET</constant> (i.e.
|
|
<varname>ListenSequentialPacket=</varname>) is only available
|
|
for <constant>AF_UNIX</constant> sockets.
|
|
<constant>SOCK_STREAM</constant> (i.e.
|
|
<varname>ListenStream=</varname>) when used for IP sockets
|
|
refers to TCP sockets, <constant>SOCK_DGRAM</constant> (i.e.
|
|
<varname>ListenDatagram=</varname>) to UDP.</para>
|
|
|
|
<para>These options may be specified more than once, in which
|
|
case incoming traffic on any of the sockets will trigger
|
|
service activation, and all listed sockets will be passed to
|
|
the service, regardless of whether there is incoming traffic
|
|
on them or not. If the empty string is assigned to any of
|
|
these options, the list of addresses to listen on is reset,
|
|
all prior uses of any of these options will have no
|
|
effect.</para>
|
|
|
|
<para>It is also possible to have more than one socket unit
|
|
for the same service when using <varname>Service=</varname>,
|
|
and the service will receive all the sockets configured in all
|
|
the socket units. Sockets configured in one unit are passed in
|
|
the order of configuration, but no ordering between socket
|
|
units is specified.</para>
|
|
|
|
<para>If an IP address is used here, it is often desirable to
|
|
listen on it before the interface it is configured on is up
|
|
and running, and even regardless of whether it will be up and
|
|
running at any point. To deal with this, it is recommended to
|
|
set the <varname>FreeBind=</varname> option described
|
|
below.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ListenFIFO=</varname></term>
|
|
<listitem><para>Specifies a file system FIFO (see <citerefentry
|
|
project='man-pages'><refentrytitle>fifo</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details) to listen on. This expects an absolute file system path as argument. Behavior otherwise is
|
|
very similar to the <varname>ListenDatagram=</varname> directive above.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ListenSpecial=</varname></term>
|
|
<listitem><para>Specifies a special file in the file system to
|
|
listen on. This expects an absolute file system path as
|
|
argument. Behavior otherwise is very similar to the
|
|
<varname>ListenFIFO=</varname> directive above. Use this to
|
|
open character device nodes as well as special files in
|
|
<filename>/proc/</filename> and
|
|
<filename>/sys/</filename>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ListenNetlink=</varname></term>
|
|
<listitem><para>Specifies a Netlink family to create a socket
|
|
for to listen on. This expects a short string referring to the
|
|
<constant>AF_NETLINK</constant> family name (such as
|
|
<varname>audit</varname> or <varname>kobject-uevent</varname>)
|
|
as argument, optionally suffixed by a whitespace followed by a
|
|
multicast group integer. Behavior otherwise is very similar to
|
|
the <varname>ListenDatagram=</varname> directive
|
|
above.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ListenMessageQueue=</varname></term>
|
|
<listitem><para>Specifies a POSIX message queue name to listen on (see <citerefentry
|
|
project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
for details). This expects a valid message queue name (i.e. beginning with
|
|
<literal>/</literal>). Behavior otherwise is very similar to the <varname>ListenFIFO=</varname>
|
|
directive above. On Linux message queue descriptors are actually file descriptors and can be
|
|
inherited between processes.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ListenUSBFunction=</varname></term>
|
|
<listitem><para>Specifies a <ulink
|
|
url="https://docs.kernel.org/usb/functionfs.html">USB
|
|
FunctionFS</ulink> endpoints location to listen on, for
|
|
implementation of USB gadget functions. This expects an
|
|
absolute file system path of a FunctionFS mount point as the argument.
|
|
Behavior otherwise is very similar to the <varname>ListenFIFO=</varname>
|
|
directive above. Use this to open the FunctionFS endpoint
|
|
<filename>ep0</filename>. When using this option, the
|
|
activated service has to have the
|
|
<varname>USBFunctionDescriptors=</varname> and
|
|
<varname>USBFunctionStrings=</varname> options set.
|
|
</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v227"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SocketProtocol=</varname></term>
|
|
<listitem><para>Takes one of <option>udplite</option>,
|
|
<option>sctp</option> or <option>mptcp</option>. The socket will use
|
|
the UDP-Lite (<constant>IPPROTO_UDPLITE</constant>), SCTP
|
|
(<constant>IPPROTO_SCTP</constant>) or MPTCP
|
|
(<constant>IPPROTO_MPTCP</constant>) protocol, respectively.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v229"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>BindIPv6Only=</varname></term>
|
|
<listitem><para>Takes one of <option>default</option>,
|
|
<option>both</option> or <option>ipv6-only</option>. Controls
|
|
the IPV6_V6ONLY socket option (see
|
|
<citerefentry project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
for details). If <option>both</option>, IPv6 sockets bound
|
|
will be accessible via both IPv4 and IPv6. If
|
|
<option>ipv6-only</option>, they will be accessible via IPv6
|
|
only. If <option>default</option> (which is the default,
|
|
surprise!), the system wide default setting is used, as
|
|
controlled by
|
|
<filename>/proc/sys/net/ipv6/bindv6only</filename>, which in
|
|
turn defaults to the equivalent of
|
|
<option>both</option>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Backlog=</varname></term>
|
|
<listitem><para>Takes an unsigned 32-bit integer argument. Specifies the number of connections to
|
|
queue that have not been accepted yet. This setting matters only for stream and sequential packet
|
|
sockets. See
|
|
<citerefentry><refentrytitle>listen</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
|
details. Defaults to 4294967295. Note that this value is silently capped by the
|
|
<literal>net.core.somaxconn</literal> sysctl, which typically defaults to 4096, so typically
|
|
the sysctl is the setting that actually matters.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>BindToDevice=</varname></term>
|
|
<listitem><para>Specifies a network interface name to bind this socket to. If set, traffic will only
|
|
be accepted from the specified network interfaces. This controls the
|
|
<constant>SO_BINDTODEVICE</constant> socket option (see <citerefentry
|
|
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details). If this option is used, an implicit dependency from this socket unit on the network
|
|
interface device unit is created
|
|
(see <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
|
|
Note that setting this parameter might result in additional dependencies to be added to the unit (see
|
|
above).</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SocketUser=</varname></term>
|
|
<term><varname>SocketGroup=</varname></term>
|
|
|
|
<listitem><para>Takes a UNIX user/group name. When specified, all <constant>AF_UNIX</constant>
|
|
sockets and FIFO nodes in the file system are owned by the specified user and group. If unset (the
|
|
default), the nodes are owned by the root user/group (if run in system context) or the invoking
|
|
user/group (if run in user context). If only a user is specified but no group, then the group is
|
|
derived from the user's default group.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v214"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SocketMode=</varname></term>
|
|
<listitem><para>If listening on a file system socket or FIFO,
|
|
this option specifies the file system access mode used when
|
|
creating the file node. Takes an access mode in octal
|
|
notation. Defaults to 0666.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>DirectoryMode=</varname></term>
|
|
<listitem><para>If listening on a file system socket or FIFO,
|
|
the parent directories are automatically created if needed.
|
|
This option specifies the file system access mode used when
|
|
creating these directories. Takes an access mode in octal
|
|
notation. Defaults to 0755.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Accept=</varname></term>
|
|
<listitem><para>Takes a boolean argument. If yes, a service instance is spawned for each incoming
|
|
connection and only the connection socket is passed to it. If no, all listening sockets themselves
|
|
are passed to the started service unit, and only one service unit is spawned for all connections
|
|
(also see above). This value is ignored for datagram sockets and FIFOs where a single service unit
|
|
unconditionally handles all incoming traffic. Defaults to <option>no</option>. For performance
|
|
reasons, it is recommended to write new daemons only in a way that is suitable for
|
|
<option>Accept=no</option>. A daemon listening on an <constant>AF_UNIX</constant> socket may, but
|
|
does not need to, call
|
|
<citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> on the
|
|
received socket before exiting. However, it must not unlink the socket from a file system. It should
|
|
not invoke
|
|
<citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry> on
|
|
sockets it got with <varname>Accept=no</varname>, but it may do so for sockets it got with
|
|
<varname>Accept=yes</varname> set. Setting <varname>Accept=yes</varname> is mostly useful to allow
|
|
daemons designed for usage with <citerefentry
|
|
project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> to work
|
|
unmodified with systemd socket activation.</para>
|
|
|
|
<para>Note that depending on this setting the services activated by units of this type are either
|
|
regular services (in case of <varname>Accept=</varname><option>no</option>) or instances of templated
|
|
services (in case of <varname>Accept=</varname><option>yes</option>). See the Description section
|
|
above for a more detailed discussion of the naming rules of triggered services.</para>
|
|
|
|
<para>For IPv4 and IPv6 connections, the <varname>$REMOTE_ADDR</varname> environment variable will
|
|
contain the remote IP address, and <varname>$REMOTE_PORT</varname> will contain the remote port. This
|
|
is the same as the format used by CGI. For <constant>SOCK_RAW</constant>, the port is the IP
|
|
protocol.</para>
|
|
|
|
<para>For <constant>AF_UNIX</constant> socket connections, the <varname>$REMOTE_ADDR</varname>
|
|
environment variable will contain either the remote socket's file system path starting with a slash
|
|
(<literal>/</literal>) or its address in the abstract namespace starting with an at symbol
|
|
(<literal>@</literal>). If the socket is unnamed, <varname>$REMOTE_ADDR</varname> won't be set.</para>
|
|
|
|
<para>It is recommended to set <varname>CollectMode=inactive-or-failed</varname> for service
|
|
instances activated via <varname>Accept=yes</varname>, to ensure that failed connection services are
|
|
cleaned up and released from memory, and do not accumulate.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Writable=</varname></term>
|
|
<listitem><para>Takes a boolean argument. May only be used in
|
|
conjunction with <varname>ListenSpecial=</varname>. If true,
|
|
the specified special file is opened in read-write mode, if
|
|
false, in read-only mode. Defaults to false.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v227"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>FlushPending=</varname></term>
|
|
<listitem><para>Takes a boolean argument. May only be used when
|
|
<option>Accept=no</option>. If yes, the socket's buffers are cleared after the
|
|
triggered service exited. This causes any pending data to be
|
|
flushed and any pending incoming connections to be rejected. If no, the
|
|
socket's buffers won't be cleared, permitting the service to handle any
|
|
pending connections after restart, which is the usually expected behaviour.
|
|
Defaults to <option>no</option>.
|
|
</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v247"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>MaxConnections=</varname></term>
|
|
<listitem><para>The maximum number of connections to simultaneously run services instances for, when
|
|
<option>Accept=yes</option> is set. If more concurrent connections are coming in, they will be refused
|
|
until at least one existing connection is terminated. This setting has no effect on sockets configured
|
|
with <option>Accept=no</option> or datagram sockets. Defaults to 64.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>MaxConnectionsPerSource=</varname></term>
|
|
<listitem><para>The maximum number of connections for a service per source IP address (in case of
|
|
IPv4/IPv6), per source CID (in case of <constant>AF_VSOCK</constant>), or source UID (in case of
|
|
<constant>AF_UNIX</constant>). This is very similar to the <varname>MaxConnections=</varname>
|
|
directive above. Defaults to 0, i.e. disabled.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v232"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>KeepAlive=</varname></term>
|
|
<listitem><para>Takes a boolean argument. If true, the TCP/IP stack will send a keep alive message
|
|
after 2h (depending on the configuration of
|
|
<filename>/proc/sys/net/ipv4/tcp_keepalive_time</filename>) for all TCP streams accepted on this
|
|
socket. This controls the <constant>SO_KEEPALIVE</constant> socket option (see <citerefentry
|
|
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
|
|
the <ulink url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP Keepalive
|
|
HOWTO</ulink> for details.) Defaults to <option>false</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>KeepAliveTimeSec=</varname></term>
|
|
<listitem><para>Takes time (in seconds) as argument. The connection needs to remain
|
|
idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE
|
|
socket option (see
|
|
<citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
and the <ulink
|
|
url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
|
|
Keepalive HOWTO</ulink> for details.)
|
|
Default value is 7200 seconds (2 hours).</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v216"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>KeepAliveIntervalSec=</varname></term>
|
|
<listitem><para>Takes time (in seconds) as argument between individual keepalive probes, if the
|
|
socket option <constant>SO_KEEPALIVE</constant> has been set on this socket. This controls the
|
|
<constant>TCP_KEEPINTVL</constant> socket option (see <citerefentry
|
|
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
|
|
the <ulink url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP Keepalive
|
|
HOWTO</ulink> for details.) Default value is 75 seconds.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v216"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>KeepAliveProbes=</varname></term>
|
|
<listitem><para>Takes an integer as argument. It is the number of
|
|
unacknowledged probes to send before considering the
|
|
connection dead and notifying the application layer. This
|
|
controls the TCP_KEEPCNT socket option (see
|
|
<citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
and the <ulink
|
|
url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
|
|
Keepalive HOWTO</ulink> for details.) Default value is
|
|
9.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v216"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>NoDelay=</varname></term>
|
|
<listitem><para>Takes a boolean argument. TCP Nagle's
|
|
algorithm works by combining a number of small outgoing
|
|
messages, and sending them all at once. This controls the
|
|
TCP_NODELAY socket option (see
|
|
<citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
|
|
Defaults to <option>false</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v216"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Priority=</varname></term>
|
|
<listitem><para>Takes an integer argument controlling the priority for all traffic sent from this
|
|
socket. This controls the <constant>SO_PRIORITY</constant> socket option (see <citerefentry
|
|
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details.).</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>DeferAcceptSec=</varname></term>
|
|
|
|
<listitem><para>Takes time (in seconds) as argument. If set,
|
|
the listening process will be awakened only when data arrives
|
|
on the socket, and not immediately when connection is
|
|
established. When this option is set, the
|
|
<constant>TCP_DEFER_ACCEPT</constant> socket option will be
|
|
used (see
|
|
<citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
|
|
and the kernel will ignore initial ACK packets without any
|
|
data. The argument specifies the approximate amount of time
|
|
the kernel should wait for incoming data before falling back
|
|
to the normal behavior of honoring empty ACK packets. This
|
|
option is beneficial for protocols where the client sends the
|
|
data first (e.g. HTTP, in contrast to SMTP), because the
|
|
server process will not be woken up unnecessarily before it
|
|
can take any action.
|
|
</para>
|
|
|
|
<para>If the client also uses the
|
|
<constant>TCP_DEFER_ACCEPT</constant> option, the latency of
|
|
the initial connection may be reduced, because the kernel will
|
|
send data in the final packet establishing the connection (the
|
|
third packet in the "three-way handshake").</para>
|
|
|
|
<para>Disabled by default.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v216"/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ReceiveBuffer=</varname></term>
|
|
<term><varname>SendBuffer=</varname></term>
|
|
<listitem><para>Takes an integer argument controlling the receive or send buffer sizes of this
|
|
socket, respectively. This controls the <constant>SO_RCVBUF</constant> and
|
|
<constant>SO_SNDBUF</constant> socket options (see <citerefentry
|
|
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details.). The usual suffixes K, M, G are supported and are understood to the base of
|
|
1024.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>IPTOS=</varname></term>
|
|
<listitem><para>Takes an integer argument controlling the IP Type-Of-Service field for packets
|
|
generated from this socket. This controls the <constant>IP_TOS</constant> socket option (see
|
|
<citerefentry
|
|
project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details.). Either a numeric string or one of <option>low-delay</option>, <option>throughput</option>,
|
|
<option>reliability</option> or <option>low-cost</option> may be specified.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>IPTTL=</varname></term>
|
|
<listitem><para>Takes an integer argument controlling the IPv4 Time-To-Live/IPv6 Hop-Count field for
|
|
packets generated from this socket. This sets the
|
|
<constant>IP_TTL</constant>/<constant>IPV6_UNICAST_HOPS</constant> socket options (see <citerefentry
|
|
project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
|
|
<citerefentry
|
|
project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details.)</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Mark=</varname></term>
|
|
<listitem><para>Takes an integer value. Controls the firewall mark of packets generated by this
|
|
socket. This can be used in the firewall logic to filter packets from this socket. This sets the
|
|
<constant>SO_MARK</constant> socket option. See <citerefentry
|
|
project='die-net'><refentrytitle>iptables</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
|
|
details.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ReusePort=</varname></term>
|
|
<listitem><para>Takes a boolean value. If true, allows multiple
|
|
<citerefentry><refentrytitle>bind</refentrytitle><manvolnum>2</manvolnum></citerefentry>s to this TCP
|
|
or UDP port. This controls the <constant>SO_REUSEPORT</constant> socket option. See <citerefentry
|
|
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v206"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SmackLabel=</varname></term>
|
|
<term><varname>SmackLabelIPIn=</varname></term>
|
|
<term><varname>SmackLabelIPOut=</varname></term>
|
|
<listitem><para>Takes a string value. Controls the extended
|
|
attributes <literal>security.SMACK64</literal>,
|
|
<literal>security.SMACK64IPIN</literal> and
|
|
<literal>security.SMACK64IPOUT</literal>, respectively, i.e.
|
|
the security label of the FIFO, or the security label for the
|
|
incoming or outgoing connections of the socket, respectively.
|
|
See <ulink
|
|
url="https://docs.kernel.org/admin-guide/LSM/Smack.html">Smack</ulink>
|
|
for details.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v196"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SELinuxContextFromNet=</varname></term>
|
|
<listitem><para>Takes a boolean argument. When true, systemd
|
|
will attempt to figure out the SELinux label used for the
|
|
instantiated service from the information handed by the peer
|
|
over the network. Note that only the security level is used
|
|
from the information provided by the peer. Other parts of the
|
|
resulting SELinux context originate from either the target
|
|
binary that is effectively triggered by socket unit or from
|
|
the value of the <varname>SELinuxContext=</varname> option.
|
|
This configuration option applies only when activated service
|
|
is passed in single socket file descriptor, i.e. service
|
|
instances that have standard input connected to a socket or
|
|
services triggered by exactly one socket unit. Also note
|
|
that this option is useful only when MLS/MCS SELinux policy
|
|
is deployed. Defaults to
|
|
<literal>false</literal>. </para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v217"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>PipeSize=</varname></term>
|
|
<listitem><para>Takes a size in bytes. Controls the pipe
|
|
buffer size of FIFOs configured in this socket unit. See
|
|
<citerefentry><refentrytitle>fcntl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
|
for details. The usual suffixes K, M, G are supported and are
|
|
understood to the base of 1024.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>MessageQueueMaxMessages=</varname>,
|
|
<varname>MessageQueueMessageSize=</varname></term>
|
|
<listitem><para>These two settings take integer values and
|
|
control the mq_maxmsg field or the mq_msgsize field,
|
|
respectively, when creating the message queue. Note that
|
|
either none or both of these variables need to be set. See
|
|
<citerefentry project='die-net'><refentrytitle>mq_setattr</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
|
for details.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>FreeBind=</varname></term>
|
|
<listitem><para>Takes a boolean value. Controls whether the socket can be bound to non-local IP
|
|
addresses. This is useful to configure sockets listening on specific IP addresses before those IP
|
|
addresses are successfully configured on a network interface. This sets the
|
|
<constant>IP_FREEBIND</constant>/<constant>IPV6_FREEBIND</constant> socket option. For robustness
|
|
reasons it is recommended to use this option whenever you bind a socket to a specific IP
|
|
address. Defaults to <option>false</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Transparent=</varname></term>
|
|
<listitem><para>Takes a boolean value. Controls the
|
|
<constant>IP_TRANSPARENT</constant>/<constant>IPV6_TRANSPARENT</constant> socket option. Defaults to
|
|
<option>false</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Broadcast=</varname></term>
|
|
<listitem><para>Takes a boolean value. This controls the <constant>SO_BROADCAST</constant> socket
|
|
option, which allows broadcast datagrams to be sent from this socket. Defaults to
|
|
<option>false</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>PassCredentials=</varname></term>
|
|
<listitem><para>Takes a boolean value. This controls the <constant>SO_PASSCRED</constant> socket
|
|
option, which allows <constant>AF_UNIX</constant> sockets to receive the credentials of the sending
|
|
process in an ancillary message. Defaults to <option>false</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>PassSecurity=</varname></term>
|
|
<listitem><para>Takes a boolean value. This controls the <constant>SO_PASSSEC</constant> socket
|
|
option, which allows <constant>AF_UNIX</constant> sockets to receive the security context of the
|
|
sending process in an ancillary message. Defaults to <option>false</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>PassPacketInfo=</varname></term>
|
|
<listitem><para>Takes a boolean value. This controls the <constant>IP_PKTINFO</constant>,
|
|
<constant>IPV6_RECVPKTINFO</constant>, <constant>NETLINK_PKTINFO</constant> or
|
|
<constant>PACKET_AUXDATA</constant> socket options, which enable reception of additional per-packet
|
|
metadata as ancillary message, on <constant>AF_INET</constant>, <constant>AF_INET6</constant>,
|
|
<constant>AF_UNIX</constant> and <constant>AF_PACKET</constant> sockets. Defaults to
|
|
<option>false</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v246"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Timestamping=</varname></term>
|
|
<listitem><para>Takes one of <literal>off</literal>, <literal>us</literal> (alias:
|
|
<literal>usec</literal>, <literal>μs</literal>) or <literal>ns</literal> (alias:
|
|
<literal>nsec</literal>). This controls the <constant>SO_TIMESTAMP</constant> or
|
|
<constant>SO_TIMESTAMPNS</constant> socket options, and enables whether ingress network traffic shall
|
|
carry timestamping metadata. Defaults to <option>off</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v247"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>TCPCongestion=</varname></term>
|
|
<listitem><para>Takes a string value. Controls the TCP congestion algorithm used by this
|
|
socket. Should be one of <literal>westwood</literal>, <literal>reno</literal>,
|
|
<literal>cubic</literal>, <literal>lp</literal> or any other available algorithm supported by the IP
|
|
stack. This setting applies only to stream sockets.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ExecStartPre=</varname></term>
|
|
<term><varname>ExecStartPost=</varname></term>
|
|
<listitem><para>Takes one or more command lines, which are
|
|
executed before or after the listening sockets/FIFOs are
|
|
created and bound, respectively. The first token of the
|
|
command line must be an absolute filename, then followed by
|
|
arguments for the process. Multiple command lines may be
|
|
specified following the same scheme as used for
|
|
<varname>ExecStartPre=</varname> of service unit
|
|
files.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ExecStopPre=</varname></term>
|
|
<term><varname>ExecStopPost=</varname></term>
|
|
<listitem><para>Additional commands that are executed before
|
|
or after the listening sockets/FIFOs are closed and removed,
|
|
respectively. Multiple command lines may be specified
|
|
following the same scheme as used for
|
|
<varname>ExecStartPre=</varname> of service unit
|
|
files.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>TimeoutSec=</varname></term>
|
|
<listitem><para>Configures the time to wait for the commands
|
|
specified in <varname>ExecStartPre=</varname>,
|
|
<varname>ExecStartPost=</varname>,
|
|
<varname>ExecStopPre=</varname> and
|
|
<varname>ExecStopPost=</varname> to finish. If a command does
|
|
not exit within the configured time, the socket will be
|
|
considered failed and be shut down again. All commands still
|
|
running will be terminated forcibly via
|
|
<constant>SIGTERM</constant>, and after another delay of this
|
|
time with <constant>SIGKILL</constant>. (See
|
|
<option>KillMode=</option> in
|
|
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
|
|
Takes a unit-less value in seconds, or a time span value such
|
|
as "5min 20s". Pass <literal>0</literal> to disable the
|
|
timeout logic. Defaults to
|
|
<varname>DefaultTimeoutStartSec=</varname> from the manager
|
|
configuration file (see
|
|
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Service=</varname></term>
|
|
<listitem><para>Specifies the service unit name to activate on
|
|
incoming traffic. This setting is only allowed for sockets
|
|
with <varname>Accept=no</varname>. It defaults to the service
|
|
that bears the same name as the socket (with the suffix
|
|
replaced). In most cases, it should not be necessary to use
|
|
this option. Note that setting this parameter might result in
|
|
additional dependencies to be added to the unit (see
|
|
above).</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>RemoveOnStop=</varname></term>
|
|
<listitem><para>Takes a boolean argument. If enabled, any file nodes created by this socket unit are
|
|
removed when it is stopped. This applies to <constant>AF_UNIX</constant> sockets in the file system,
|
|
POSIX message queues, FIFOs, as well as any symlinks to them configured with
|
|
<varname>Symlinks=</varname>. Normally, it should not be necessary to use this option, and is not
|
|
recommended as services might continue to run after the socket unit has been terminated and it should
|
|
still be possible to communicate with them via their file system node. Defaults to
|
|
off.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v214"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Symlinks=</varname></term>
|
|
<listitem><para>Takes a list of file system paths. The specified paths will be created as symlinks to the
|
|
<constant>AF_UNIX</constant> socket path or FIFO path of this socket unit. If this setting is used, only one
|
|
<constant>AF_UNIX</constant> socket in the file system or one FIFO may be configured for the socket unit. Use
|
|
this option to manage one or more symlinked alias names for a socket, binding their lifecycle together. Note
|
|
that if creation of a symlink fails this is not considered fatal for the socket unit, and the socket unit may
|
|
still start. If an empty string is assigned, the list of paths is reset. Defaults to an empty
|
|
list.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v214"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>FileDescriptorName=</varname></term>
|
|
<listitem><para>Assigns a name to all file descriptors this
|
|
socket unit encapsulates. This is useful to help activated
|
|
services identify specific file descriptors, if multiple fds
|
|
are passed. Services may use the
|
|
<citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
|
call to acquire the names configured for the received file
|
|
descriptors. Names may contain any ASCII character, but must
|
|
exclude control characters and <literal>:</literal>, and must
|
|
be at most 255 characters in length. If this setting is not
|
|
used, the file descriptor name defaults to the name of the
|
|
socket unit, including its <filename>.socket</filename>
|
|
suffix.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v227"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>TriggerLimitIntervalSec=</varname></term>
|
|
<term><varname>TriggerLimitBurst=</varname></term>
|
|
|
|
<listitem><para>Configures a limit on how often this socket unit may be activated within a specific
|
|
time interval. The <varname>TriggerLimitIntervalSec=</varname> setting may be used to configure the
|
|
length of the time interval in the usual time units <literal>us</literal>, <literal>ms</literal>,
|
|
<literal>s</literal>, <literal>min</literal>, <literal>h</literal>, … and defaults to 2s (See
|
|
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
|
details on the various time units understood). The <varname>TriggerLimitBurst=</varname> setting
|
|
takes a positive integer value and specifies the number of permitted activations per time interval,
|
|
and defaults to 200 for <varname>Accept=yes</varname> sockets (thus by default permitting 200
|
|
activations per 2s), and 20 otherwise (20 activations per 2s). Set either to 0 to disable any form of
|
|
trigger rate limiting.</para>
|
|
|
|
<para>If the limit is hit, the socket unit is placed into a failure mode, and will not be connectible
|
|
anymore until restarted. Note that this limit is enforced before the service activation is
|
|
enqueued.</para>
|
|
|
|
<para>Compare with <varname>PollLimitIntervalSec=</varname>/<varname>PollLimitBurst=</varname>
|
|
described below, which implements a temporary slowdown if a socket unit is flooded with incoming
|
|
traffic, as opposed to the permanent failure state
|
|
<varname>TriggerLimitIntervalSec=</varname>/<varname>TriggerLimitBurst=</varname> results in.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v230"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>PollLimitIntervalSec=</varname></term>
|
|
<term><varname>PollLimitBurst=</varname></term>
|
|
|
|
<listitem><para>Configures a limit on how often polling events on the file descriptors backing this
|
|
socket unit will be considered. This pair of settings is similar to
|
|
<varname>TriggerLimitIntervalSec=</varname>/<varname>TriggerLimitBurst=</varname> but instead of
|
|
putting a (fatal) limit on the activation frequency puts a (transient) limit on the polling
|
|
frequency. The expected parameter syntax and range are identical to that of the aforementioned
|
|
options, and can be disabled the same way.</para>
|
|
|
|
<para>If the polling limit is hit polling is temporarily disabled on it until the specified time
|
|
window passes. The polling limit hence slows down connection attempts if hit, but unlike the trigger
|
|
limit won't cause permanent failures. It's the recommended mechanism to deal with DoS attempts
|
|
through packet flooding.</para>
|
|
|
|
<para>The polling limit is enforced per file descriptor to listen on, as opposed to the trigger limit
|
|
which is enforced for the entire socket unit. This distinction matters for socket units that listen
|
|
on multiple file descriptors (i.e. have multiple <varname>ListenXYZ=</varname> stanzas).</para>
|
|
|
|
<para>These setting defaults to 150 (in case of <varname>Accept=yes</varname>) and 15 (otherwise)
|
|
polling events per 2s. This is considerably lower than the default values for the trigger limit (see
|
|
above) and means that the polling limit should typically ensure the trigger limit is never hit,
|
|
unless one of them is reconfigured or disabled.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v255"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>PassFileDescriptorsToExec=</varname></term>
|
|
|
|
<listitem><para>Takes a boolean argument. Defaults to off. If enabled, file descriptors created by
|
|
the socket unit are passed to <varname>ExecStartPost=</varname>, <varname>ExecStopPre=</varname>, and
|
|
<varname>ExecStopPost=</varname> commands from the socket unit. The passed file descriptors can be
|
|
accessed with
|
|
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> as
|
|
if the commands were invoked from the associated service units. Note that
|
|
<varname>ExecStartPre=</varname> command cannot access socket file descriptors.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
<xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para><simplelist type="inline">
|
|
<member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry></member>
|
|
</simplelist></para>
|
|
<para>
|
|
For more extensive descriptions see the "systemd for Developers" series:
|
|
<simplelist type="inline">
|
|
<member><ulink url="https://0pointer.de/blog/projects/socket-activation.html">Socket Activation</ulink></member>
|
|
<member><ulink url="https://0pointer.de/blog/projects/socket-activation2.html">Socket Activation, part II</ulink></member>
|
|
<member><ulink url="https://0pointer.de/blog/projects/inetd.html">Converting inetd Services</ulink></member>
|
|
<member><ulink url="https://0pointer.de/blog/projects/socket-activated-containers.html">Socket Activated Internet Services and OS Containers</ulink></member>
|
|
</simplelist>.
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|