On Sun, Jun 18, 2023 at 8:00 PM Ferenc Wágner <wf...@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
