I stopped a service this morning and it refused to stay stopped. systemctl stop foo returned clean, no error, and a second later the thing was running again. I did it three more times, like an idiot, before I accepted that the machine was not haunted and I had simply forgotten how socket activation works.
Here is the short version, because the long version cost me twenty minutes. The unit had a sibling. foo.service had a foo.socket next to it, and the socket was enabled. When I stopped the service, the socket happily kept listening on the port. The next connection (a health check, in this case, every ten seconds) hit the socket, and systemd did exactly what it was told to do: it started foo.service to handle the traffic. I was stopping the cook while leaving the front door open and a queue of customers outside.
The giveaway was in the journal, once I actually read it instead of staring at the process list:
systemd[1]: foo.socket: Incoming traffic
systemd[1]: Starting foo.service...
"Incoming traffic". The socket was the parent. So the fix was to stop the right thing:
systemctl stop foo.socket foo.service
Stop the socket first, then the service, and it stays down. If you actually want it gone until you say otherwise, systemctl disable --now foo.socket so it does not come back on the next boot either. Mask it if you want to be properly rude about it.
None of this is a systemd bug, which is the annoying part. It is doing precisely what socket activation is for: start a service lazily when something needs it, tear it down when idle. That is genuinely useful behaviour. It is only confusing when you have inherited a box and the socket unit is the bit nobody mentioned in the handover notes.
The lesson I keep relearning is to ask "what else is this unit attached to" before I assume a service is misbehaving. systemctl list-dependencies foo.service and a quick look for a matching .socket, .timer or .path would have saved me the whole pantomime. A timer respawns on a schedule, a path unit respawns on a file change, a socket respawns on a connection. Same surprise, different trigger.
So: it was not undead. It was just well configured, by someone who was not me, for a purpose I had forgotten existed.