<div dir="ltr"><div><div><div>Hi,<br><br></div>I have a daemon that is socket-activated through a systemd-managed localhost TCP socket. The daemon is normally shutdown by a simple systemctl stop with ExecStop=curl -X POST on the right HTTP endpoint which makes it easy to cleanup resources and make sure my data hits the hard disk.<br><br></div><div>Now, it just so happens that sometimes my users and myself screw up and we actually invoke the stop HTTP endpoint by hand because we are dumb. When this happens, systemd detects that the daemon dies peacefully (status = 0) and then proceeds to invoke ExecStop=curl -X POST (service_enter_running calls service_enter_stop). The latter never completes because systemd still has the activation socket open so curl waits forever for the TCP connection to be accepted (modulo timeout). When the timeout expires, systemd tries to re-run ExecStop. When I "kill -9" the command by hand, systemd tries to re-run ExecStop.<br><br></div><div>voila, deadlock: systemd waits for ExecStop to finish, ExecStop waits for systemd to start daemon to be able to stop it.<br><br></div><div>Now, I am sure that what I did (use the activation socket as the channel over which stop commands are safely sent) is not right but I wonder if there is a way to make systemd actually deal with the situation better and if not, what I should do instead to deal with someone trying to shutdown the daemon without "systemctl stop".<br><br></div><div>I would be happy to file a bug if needed but I am not really sure the problem lies in systemd. Or maybe it is a documentation problem: it would help quite a bit if the activation state machine/transitions was documented in a human-readable way beyond what can be found by reading the source code.<br></div><div><br></div><div>any help would be welcome,<br></div>Mathieu<br></div></div>