> 1) It's still al just Wants, no Requires... i.e. if netfilter rules loading fails for whichever reason, the boot process will continue just normally, with networking and any daemons, that possibly require netfilter for their security, being brought up.
There is a separate bug report for this: 'netfilter-persistent systemd service does not lock the network if netfilter-persistent wrapper is failing at system bootup' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829752 I guess let's please use that one. > 2) Some daemons might actually improperly start even before network.target or network-pre.target... while this is certainly bad, it likely happens in the realworld... so a dependency (or at least a Wants) on something much earlier would be useful... e.g. sysinit.target, which I use for that. Not sure about that. Not sure we should add workarounds here to fix grave bugs in other packages. Do you have an real world examples? And even if daemons start before network-pre.target, it should be save, since network is not up at that point? And by the time network is up, the firewall will be up earlier. Please consider creating a new bug report if you still think that is an issue. > 3) I don't quite understand the benefit of: > Conflicts=shutdown.target > Before=shutdown.target Understandably. The benefits are minor. - It is the correct thing to do as per systemd documentation. - It will result in a more correct (and perhaps slightly faster) shutdown. The service gets terminated just as any other service. No systemd auto cleanup for still running services after shutdown.target code paths will be needed. > Doesn't this actually open a possible window int which daemons may still run but netfilter-persistent is going to be stopped and thus rules might be removed? No, because the systemd service will be stopped using "service netfilter-persistent stop" - which by default does nothing, does not remove and iptables rules. It does not run "service netfilter-persistent flush". You can verify this by making your firewall plugins verbose. (In case of bash, xtrace, 'set -x'.) Then shutdown and watch your syslog / journalctl of your last shutdown. It might be an issue for users using netfilter-persistent configration option FLUSH_ON_STOP, but I have no idea who on earth would enable this anyhow. Perhaps that option should be removed, but that is worth another bug report. Thank you for also thinking all of this through, more eyes are certainly helpful! Cheers, Patrick
