Package: ifupdown Version: 0.8.19 Severity: important Hi Guus,
I've been updating another (local) package to deal with systemd no longer running rcS.d init scripts in Stretch - which means I've been looking carefully at the boot sequencing on both Jessie and Stretch, and there's a notable change in the ordering of networking.service between those two releases, which seems to have potential for trouble. In Jessie, the generated unit guaranteed that ifup would be run Before=sysinit.target based on it being ordered in rcS.d - and so equivalently that ifdown would not be run until everything ordered after sysinit.target was already shut down. In the explicit unit in Stretch, that ordering relation is no longer present, and networking.service starts much later - including after basic.target, which potentially pulls in remote filesystem mounts. There seems to be a few subtle consequences to this - I now see a bunch of services which do need/use network connectivity get started before networking.service. Arguably some are also buggy for not having an ordering After=network.target (munin-node I'm looking at you), but for some like rsyslog that may or may not be needed depending on other configuration. But not being ordered to start before / stop after remote mounts can be sequenced seems to be something networking.service itself should fix. Is there any good reason this should not (still) declare an ordering Before=sysinit.target ? It's quite possible that bugs like #857679 are caused by this (note that 'dependency' relationships as shown by the reporter aren't the same as ordering relationships ...). And bugs like #857573 if not directly caused by it would be exacerbated by it making the other issues harder to fix at their root too. There may be others, but that was two that stood out while I looked to see if this was already reported. Thanks for picking up the maintenance of this package! Best, Ron
