<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 18, 2023 at 8:00 PM Ferenc Wágner <<a href="mailto:wferi@niif.hu">wferi@niif.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
As an example, please consider rabbitmq-server.service, which is an<br>
Erlang application, so it uses the services of the Erlang Port Mapper<br>
Daemon (epmd), which is socket-activated:<br>
<br>
# /lib/systemd/system/rabbitmq-server.service<br>
[Unit]<br>
After=epmd.socket<br>
Wants=epmd.socket<br>
<br>
# /lib/systemd/system/epmd.service<br>
[Unit]<br>
After=network.target<br>
Requires=epmd.socket<br>
<br>
# /lib/systemd/system/epmd.socket<br>
[Install]<br>
WantedBy=sockets.target<br>
<br>
Side question: rabbitmq-server does not specify DefaultDependencies=no,<br>
are After/Wants=epmd.socket necessary there?  Isn't the implicit<br>
After=basic.target enough?<br></blockquote><div><br></div><div>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=.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But anyway, this achieves a stable and maximally parallel startup.<br>
<br>
However, problems arise during shutdown, because the ExecStop command of<br>
rabbitmq-server.service uses epmd as well, but epmd.service can be<br>
stopped earlier and won't be reactivated (epmd.socket: Suppressing<br>
connection request since unit stop is scheduled; as an additional detail<br>
rabbitmq-server then tries to start its own epmd and fails because<br>
epmd.socket still holds the address, but this is irrelevant here).  So<br>
after much struggle ExecStop fails and the unit is brought down anyway,<br>
but the failure message already polluted the logs.<br>
<br>
This can be worked around by adding After=epmd.service to<br>
rabbitmq-server.service, but that pretty much defeats the advantages of<br>
socket activation by sequencing startups and being explicit about<br>
dependencies.  Now rabbitmq-server and epmd are just examples here, any<br>
service using a socket-activated service during its shutdown is<br>
affected and prone to timeouts or failures.<br></blockquote><div><br></div><div>Not entirely sure here, but I *think* this might be unavoidable.<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>