On Tue, Jun 09, 2015 at 06:27:37PM +0200, Guus Sliepen wrote: > Hi, I just adopted ifupdown from Andrew Shadura. Incidentally I'm also > the ifenslave maintainer :)
Hello Guus, good luck with maintaining ifupdown :) The outline for this change is the way the interfaces are handled by upstart in Ubuntu. They are all brought up in parallel by independent processes, so there was a need for a universal mechanism to ensure the proper order of initialization in more complex scenarios. > > It is of course not so nice to have to specify those groups by hand, > especially to assign numbers to them. It would be nicer to just have a > statement you can put in an interface stanza that tells you which > interfaces are depending on it, like: > > iface bond0 inet static > depending-interfaces eth0 eth1 > > This could then implicitly generate the same groups as you have to > specify explicitly in your case. I agree with that, it will surely be more user-friendly and will make /e/n/interfaces easier to read. > Even better would be to have the race condition be dealt with without > any changes to /e/n/interfaces. One issue is of course that the > /r/n/ifstate file is only locked to update the state, and there is no > state indicating that an interface is in the process of being > configured. So indeed, a per-interface lockfile should be used, which > will be locked for the whole duration the interface is being > (de)configured. Something like /r/n/ifstate-bond0, which is locked using > fcntl(), and into which the process holding the lock will write the > state (up/down). To prevent deadlocks (scripts calling ifup/ifdown > recursively), environment variables are set to indicate which interfaces > are being configured, like IFUPDOWN_bond0=up, and before trying to lock > the per-interface lockfile, presence of this environment variable is > checked. I already have an implementation of the deadlock detection, but > not yet of per-interface lockfiles. Is this implementation for detecting deadlocks available anywhere for examination? The mechanism I implemented takes care of deadlocks by enforcing consistent order of interface locking and disables further locking in recurrent ifupdown invocations with an env variable. > But in the case of bonding, there is already a mechanism in place that > can prevent conflicts between ifup -a and ifup bond0 running > simultaneously. If you write /e/n/interfaces like this: > > allow-bond0 eth0 > iface eth0 inet manual > bond-master bond0 > > allow-bond0 eth1 > iface eth1 inet manual > bond-master bond0 > > auto bond0 > iface bond0 inet dhcp > bond-slaves eth0 eth1 > ... > > Note that I replaced "auto" with "allow-bond0" for the Ethernet > interfaces. This causes ifup -a to skip those interfaces, but instead > will cause ifup bond0 to run ifup eth0 and eth1. Is this allow-bond0 stanza also going to work with e.g. vlans launched on top of bonding interfaces? In case of parallel interface initialization we would like to ensure that vlans are initialized after bonding interfaces are brought up. If it does solve this problem as well possibly no other modifications to ifupdown are needed in the scenario I need to handle. If it does not - I will try to alter my current implementation to use per-interface stanzas. > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <g...@debian.org> Regards, Dariusz Gadomski
signature.asc
Description: Digital signature
