I stopped a service and it came back. I stopped it again, watched it report inactive, dead, and a few seconds later there it was in systemctl status, green and running, as if I had imagined the whole thing. There is a specific flavour of paranoia that sets in when a machine appears to be ignoring you, and I had it badly for about ten minutes before I remembered that systemd is not haunted, it is just doing exactly what someone told it to.
The first thing I did was the obvious thing, and the obvious thing lied to me:
systemctl stop myapp.service
systemctl status myapp.service
Inactive. Good. Then a request came in, and it was running again. That timing is the tell, and it took me one more cycle to actually notice it: the service did not resurrect on a timer, it resurrected the moment something tried to use it.
The culprit was socket activation, which I had set up myself months earlier and entirely forgotten. There was a myapp.socket unit listening on the port, and stopping myapp.service does nothing to the socket. The socket stays open, holds the port, and the instant a connection arrives systemd starts the service to handle it. I was stopping the actor and leaving the doorbell wired up. Of course it came back. I had told it to.
systemctl stop myapp.socket myapp.service
Stop the socket as well and the resurrection stops. If you want it gone properly until you say otherwise, mask it, which points the unit at /dev/null so nothing, not a socket, not a dependency, not a careless start, can bring it up:
systemctl mask myapp.service
There is a second way this same trick gets you, and it is worth knowing because the symptom is identical. A unit with Restart=always and a short RestartSec will pop straight back up after a stop if it exits non-zero on the way out, or if something racing you sends it work. systemctl stop should override the restart policy, but I have watched people fight a flapping unit for ten minutes because they were stopping it while their own monitoring kept poking it awake. The fix is the same: find the thing that is starting it, not just the thing that is running.
The lesson is an old one wearing new clothes. When a process will not stay dead, the question is never "why won't it die." It is "what keeps starting it." Under sysvinit that was usually respawn in inittab or a watchdog cron. Under systemd it is a socket, a path unit, a timer, or a Restart= line, and the unit you are glaring at is rarely the one with its hand on the switch. Look up the dependency tree, not down at the process.