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 files). The name
of the .service unit is by default the same as the
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 files). The name
of the .service unit is by default the same as the
option described below, this .service unit must either
be named like the .socket unit, but with the suffix
replaced, unless overridden with
option described below, this .service unit must either
be named like the .socket unit, but with the suffix
replaced, unless overridden with
<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
<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
<para>Note that the daemon software configured for
socket activation with socket units needs to be able
<para>Note that the daemon software configured for
socket activation with socket units needs to be able
before the interface it is configured
on is up and running, and even
regardless of whether it will be up and
before the interface it is configured
on is up and running, and even
regardless of whether it will be up and
it is recommended to set the
<varname>FreeBind=</varname> option
described below.</para></listitem>
it is recommended to set the
<varname>FreeBind=</varname> option
described below.</para></listitem>
<varname>Accept=no</varname>. It
defaults to the service that bears the
same name as the socket (with the
<varname>Accept=no</varname>. It
defaults to the service that bears the
same name as the socket (with the