[systemd-devel] Correct shutdown ordering with socket-activated dependencies

[Mantas Mikulėnas]

On Sun, Jun 18, 2023 at 8:00 PM Ferenc Wágner <wferi at niif.hu> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230618/1ffbe791/attachment.htm>