Am 08.07.2014 22:50, schrieb Stefano Zacchiroli: > Now the questions/comments: > > - I've had that script since ever, basically, and it used to work fine > in the past, both before and after switching to systemd as init. I'm > not sure why/when it stopped working. > > - As a mere user, the above script is perfectly reasonable, I *do* want > to restart my firewall every time my network interface is brought up, > and AFAICT I'm using the right "API" to do so.
I had a look at the shorewall(6) init script. It has # Required-Start: $network $remote_fs Now, $network is provided by the networking init script. As long as this init script is not fully started, $network (or network.target) is not yet available. You've started shorewall as part of the if-up up, when $network is not yet available, thus there is a dead lock. So, it's actually exactly the same problem as with the NFS hook. sysvinit doesn't bother, as it doesn't consider such dynamic dependencies during runtime whereas systemd does. What has changed is, that systemd_204-9 gained support for LSB system facilities, i.e. now it understands that /etc/init.d/networking provides $network. This is most likely the reason you didn't see it in the past. So, what to do about this: I'd say it's a bug to (re)start a SysV init script from an if-up.d hook without actually checking if the service is actually already runnig. Because you simply disregard any dependencies which have been specified in the LSB header. It's problematic in general to (re)start SysV init scripts from any hook (if-up.d, dhcp etc), since you can't ensure at that point that its dependencies are actually all available. I personally would consider this a local (mis)configuration which simply didn't show up with sysvinit which only computes dependencies at install time and only between init scripts in /etc/rc?.d/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
