I ran systemctl stop importer, watched it go inactive, and ten seconds later there it was again, active and cheerful, like I'd never said anything. Stopped it again. Same thing. The unit refused to stay dead, and for a few minutes I genuinely wondered if the machine was haunted.
It wasn't haunted. It was two things wearing one costume. The unit had Restart=always with RestartSec=10, which is fine on its own: stop a unit cleanly and systemd respects that, it only restarts on failure or unexpected exit. But this unit was also listed as a Requires= of a second, higher-level target that something on the box kept re-triggering via a path unit watching a spool directory. Every time a file landed in the spool, the path unit activated the target, the target pulled importer back in as a hard dependency, and up it came. My stop was real, and so was the resurrection thirty seconds later.
The tell is in the journal. Stop something and watch what reactivates it:
systemctl stop importer
journalctl -u importer -f
You'll see the next start line, and crucially the surrounding lines naming the job that requested it. Once I saw importer.service: Triggering OnUnitActiveSec was the wrong guess and the real trigger was the path unit's target, it was obvious.
To actually take it out of service I masked it: systemctl mask importer, which points the unit at /dev/null so nothing, not even a dependency, can start it. That's the difference between stop (I'd like it off now) and mask (it is not allowed to exist). When you've got something reaching for a unit from another direction, stop is a suggestion and mask is the law.