This big lock approach does not work the way it was suggested. During ifupdown development several attempts were made to avoid race conditions (fine grained locking mechanism).
The thing is that, IMHO, they do not take in consideration every possible combination with external scripts (called from /etc/network/if-pre-up.d/*) nor any possible achievement (ex: ifenslave, which calls ifup in a reentrant way for slave interfaces, one of the causes for the global lock approach to go wrong). This can be seen on the bug description. Instead of using the locking mechanism implemented today (locking ifstate.lock file), or the big lock approach (which I suggested in the beginning of this bug), I'll change the locking mechanism to create one lock file per interface (suggestions ?). With that, when an interface is being setup no other call to ifupdown binary can change that interface parameters. Obs: For "-a" (all) option, it will have to obtain every interface lock file to run. Hopefully this will guarantee that 1 interface configuration will not be raced by other ifupdown call from the beginning of the interface configuration (even when calling if-pre-up.d/if-down.d scripts) to the end of that interface configuration (even if it calls if-up.d/if-post-down.d) -> to be tested before patch submission (soon). Any comments or suggestions are welcome. Thank you Rafael Tinoco
signature.asc
Description: Message signed with OpenPGP using GPGMail
