corridor-init-forwarding.service use Before=shutdown.target Conflicts=shutdown.target

[adrelanos]

When using DefaultDependencies=No, also

Before=shutdown.target
Conflicts=shutdown.target

should be used. (I learned that from you, @rustybird, I think.)

https://github.com/rustybird/corridor/blob/master/systemd/corridor-init-forwarding.service.in

[rustybird]

Should we really remove the CORRIDOR_FILTER chain on shutdown? Doing so seems harmless (corridor-stop-forwarding sets net.ipv4.ip_forward=0 first), still looks a little weird though.

[rustybird]

Oh I think I remember what you're referring to. My understanding is that DefaultDependencies=no does not mean you should necessarily use these directives, however, if you want such a service to be stopped on shutdown, then you should use both Before and Conflicts (not just one of the two).

[adrelanos]

netfilter-persistent solves this by not unloading iptables rules by making a difference between:

• service netfilter-persistent stop (does not flush iptables rules)
• service netfilter-persistent flush (does flush iptables rules)

(Should not be an issue anyhow since networking would be systemd stopped before the firewall.)

It's rather minor. What does systemd do if services are still running after shutdown.target was reached? Does it force stop them? Does that slow down shutdown (waiting for timeouts) or otherwise have adverse effects?

Using Before=shutdown.target Conflicts=shutdown.target seems more correct, since it avoids the above.

[rustybird]

What does systemd do if services are still running after shutdown.target was reached? Does it force stop them?

It sounds like the services remain active. Not sure if leftover child processes get killed, but that's not an issue with oneshot services.

Closing this, but please reopen if you find that not having {Conflicts,Before}=shutdown.target causes slowdowns or other problems.