[yread]

ExecStop works the way you want for type=forking

[ww520]

Still has the same problem even with type=forking. Only way to get it working was RemainAfterExit=yes

[shawnz]

I think you actually probably want type=oneshot (and also RemainAfterExit=yes) for the kind of service you're describing

[brirec]

This was ultimately what I needed to do when I wrote a systemd service that managed some firewall rules. It really was a footgun though, what with having essentially different meanings/purposes for ExecStop whether you’re doing a Type=forking, a Type=oneshot, or a Type=oneshot with RemainAfterExit=yes.

And relatedly, I honestly have no idea when I’d want to use ExecStartPre, or multiple ExecStarts, or ExecStartPost, and so on.

[ww520]

Having different semantics with different proprieties on the same command is really confusing.

[shawnz]

I would argue the semantics of ExecStop are always the same. It's the command that's executed to stop the service. On the other hand, what it means for a service to be "running" or "stopping" naturally depends on what type of service it is (i.e., is it a daemon or not?)

[ww520]

> the command that's executed to stop the service

That’s what is assumed. But in reality it runs after the started process stops.

[yencabulator]

Think of it as an enum, Type branches the logic.

    enum Service {
        Exec { ExecStart: String, ... }
        Forking { ExecStart: String, ... }
        OneShot { ExecStart: String, ... }
    }

You can argue that sometimes that ExecStart could be a different term, but it'd still end up being the same across multiple enum variants.

[ww520]

Yes. ExecStart works the same for all the cases. ExecStop works differently though. While ExecStart is the event to kick off the command for the service, ExecStop is not. The asymmetric semantics are where the confusion comes from.

[BenjiWiebe]

It's been enlightening to me to read through some of the distro-provided .service files to see what can be done, with services I'm more of less familiar with.