init.d/quagga has erroneous $remote_fs in LSB headers

[Robert Dawson]

The LSB headers for quagga init script has $remote_fs in Required-Start and Required-Stop fields. This means that NFS mounts should be started before quagga sets the IP addresses on the machine, and causes NFS/netdev mounting to fail during the boot process on Trusty systems, due to insserv applying dependencies.

This causes a similar, but related, issue on Xenial where systemd generates a service file that has a similar requirement in it. Debugging that raised the awareness of this particular issue - although upstream appears to be systemd-specific, so newer package versions for Xenial may resolve this issue.

Package version is 0.99.22.4-3ubuntu1.3 on trusty 14.04.5; 0.99.24.1-2ubuntu1.4 on xenial 16.04.4; I have not verified artful, not having any in our network. Yet.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Doesn't this depend on the way round your particular setup is? It makes sense to depend on $remote_fs if your system requires it to boot, for example, and the access to the remote filesystems is _not_ over the network that is managed by quagga. I'd expect this to be the normal case, as it seems like quite a bit of server overloading to be putting quagga on the same instance as something serving files, for example.

You edit files in /etc directly to suit your specific needs; packaging is designed not to stomp on your changes.

Therefore it's not clear to me that this is a bug; rather it's just that the default configuration shipped is the opposite of what you happen to need in your particular case.

Accordingly I'm setting the status to Incomplete, but if you disagree, please feel free to explain and reopen.

[Robert Dawson (rdawson-vdms)]

I think the issue is, this particular prerequisite is not in upstream, either. The debian packages zebra.service doesn't require remote_fs (or the systemd equivalent), just network.target.

While I don't discount your point, it's not exactly obvious that this is the behaviour - perhaps some commentary in the init.d headers might be appropriate?

[Christian Ehrhardt  (paelzer)]

The newer versions already avoid that by no more being after mounts, only in between network-pre and network.

Wants=network.target
Before=network.target
After=network-pre.target

The subservices (bgpd, ripd, ...) are all integrated after zebra in between the same to network-pre/network and bind start/stop to zebra itself
BindsTo=zebra.service
Wants=network.target
After=zebra.service network-pre.target
Before=network.target

That said the issue you mentioned is fixed in newer releases as you assumed.
So let us look at the older releases.

Changing the dependencies of these releases now - as outlined there are cases that can need that - will be too much regression risk.
Suggesting a comment in the config/init is a nice suggestion, but IMHO not worth to ship an update for through the SRU policy.

Instead of a comment change in the old release I'd personally personally think this bug is already good (as it can be found by search engines) - maybe one should write a good askubuntu entry about it?
That would probably be read more often than the comment in the init file?
Opinions?