I stopped a service. It came back. I stopped it again, watched it for a few seconds, and it came back again. systemctl stop foo returned cleanly every time, no error, and yet systemctl status foo was cheerfully green within a second or two. This is the sort of thing that makes you question whether you typed the right unit name, so I checked. I had.
The first instinct is always Restart=. And yes, the unit had Restart=always in it, which means systemd will faithfully bring the thing back the moment it exits. But that is not what stop does. Stop sends SIGTERM and, critically, tells systemd you meant it, so the restart logic should not fire. If a unit comes back after a clean stop, the restart counter is not your problem. Something else is starting it.
The something else, in my case, was a socket unit. There was a foo.socket sitting alongside foo.service, and socket activation does exactly what it says: the first connection to the socket starts the service. I had a health check hammering the port every few seconds, so the instant systemd tore the service down, the next probe knocked on the door and woke it straight back up. The service was not refusing to die. It was being resurrected on a schedule, by me, via a monitor I had forgotten I set up.
$ systemctl list-units --type=socket | grep foo
foo.socket loaded active listening Foo Activation Socket
There it was. The fix is dull, which is how you know it is right:
systemctl stop foo.socket foo.service
Stop the socket as well, in the same breath, and the service stays down. If you want it gone for good, disable --now both. The lesson I keep relearning is that systemd is not one object per name, it is a small graph of related units, and stopping a service while leaving its socket armed is like switching off a light while leaving the motion sensor on. Check systemctl list-dependencies and list-units --type=socket before you decide a unit is haunted. It almost never is.