I ran systemctl stop thing and the service stopped. For about ten seconds. Then it was back, new PID, cheerful as anything, ignoring my clearly expressed wishes. I stopped it again. It came back again. At which point I started to take it personally.
The unit had Restart=always. That on its own is fine and usually what you want. The catch is the interaction: when you stop a service, systemd does send the kill, the process does die, and Restart= does not fire, because a clean stop is not a failure. But this unit also had a .path watcher and a separate timer poking at it, and the timer was happily re-starting it on schedule. I was stopping the service while something else was, by design, starting it. Two of us, working at cross purposes, and the timer had more patience than I did.
The giveaway was in the journal:
systemctl list-timers --all | grep thing
journalctl -u thing.service -n 30
The journal showed the start being triggered "by thing.timer" every thirty seconds, plainly stated, right there, the whole time I'd been blaming Restart=. To actually make it stay down I had to stop and disable the trigger, not just the service:
systemctl stop thing.timer thing.path thing.service
systemctl disable thing.timer thing.path
Stopping a service tells it to stop now. It says nothing about who's allowed to start it again. If something keeps coming back, the question isn't why won't it die, it's who keeps reviving it, and list-timers plus a careful read of the journal usually names the culprit. It's almost never the unit being stubborn. It's me forgetting I built a butler whose entire job is to switch it back on.