On Sun, Jun 18, 2023 at 8:00 PM Ferenc Wágner <wferi@xxxxxxx> wrote:
Hi,
As an example, please consider rabbitmq-server.service, which is an
Erlang application, so it uses the services of the Erlang Port Mapper
Daemon (epmd), which is socket-activated:
# /lib/systemd/system/rabbitmq-server.service
[Unit]
After=epmd.socket
Wants=epmd.socket
# /lib/systemd/system/epmd.service
[Unit]
After=network.target
Requires=epmd.socket
# /lib/systemd/system/epmd.socket
[Install]
WantedBy=sockets.target
Side question: rabbitmq-server does not specify DefaultDependencies=no,
are After/Wants=epmd.socket necessary there? Isn't the implicit
After=basic.target enough?
It might be enough on boot, but not necessarily on manual start. If you (or the package manager) directly run `systemctl start rabbitmq-server`, the socket would not be started unless it's explicitly listed in Wants/Requires=.
But anyway, this achieves a stable and maximally parallel startup.
However, problems arise during shutdown, because the ExecStop command of
rabbitmq-server.service uses epmd as well, but epmd.service can be
stopped earlier and won't be reactivated (epmd.socket: Suppressing
connection request since unit stop is scheduled; as an additional detail
rabbitmq-server then tries to start its own epmd and fails because
epmd.socket still holds the address, but this is irrelevant here). So
after much struggle ExecStop fails and the unit is brought down anyway,
but the failure message already polluted the logs.
This can be worked around by adding After=epmd.service to
rabbitmq-server.service, but that pretty much defeats the advantages of
socket activation by sequencing startups and being explicit about
dependencies. Now rabbitmq-server and epmd are just examples here, any
service using a socket-activated service during its shutdown is
affected and prone to timeouts or failures.
Not entirely sure here, but I *think* this might be unavoidable.
--
Mantas Mikulėnas
