Correct shutdown ordering with socket-activated dependencies

[Ferenc Wágner <wferi@xxxxxxx>]

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?

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.

What would be a good approach in such cases?
-- 
Thanks,
Feri.