Comment 16 for bug 1337873

Im getting back to this after sometime. After the discussion was brought to upstream we did not get feedback regarding proposed changes but investigating further it is clear that ifupdown is suffering from race conditions that cannot be solved simply by creating:

1) big lock - since its ifup/ifdown/ifquery are reentrant*
2) big lock - does not attend to interface order/priority for parallel executions**
3) fine-grained lock - does not attend interface order/priority for parallel executions**

* could be solved by ENV variable being set not to lock childs) by up/down scripts.
** group of interfaces such as "bridges" and all interfaces connected to it, interfaces and all vlans connected to it

Final approach here will be to guarantee:

1) interfaces should be locked independently on executions
2) locks have to respect interface hierarchy (locking group of inter-connected interfaces such as bridges/interfaces, interfaces/vlans)
3) all up/down scripts have to be reviewed after any locking mechanism change (deadlock by reentrant calls)

IMO

1) stanzas should be created to "group" interfaces to be locked (for parallel executions) respecting hierarchy/order between them
2) locking/state have to be together and independent

FINALLY

The change to guarantee all that will involve code AND interfaces file change (for adding special stanzas to make sure appropriate order and locking is done during interfaces activation). It is not clear if this change will be smooth enough for a "stable release update". If not I'll try to provide a PPA to address any needed code-change for those who suffer from this issue.

BY NOW

The only way to guarantee interfaces activation ordering (without suffering from intermittent race conditions like the one explained on this bug) would be to activate interface one by one outside sysv/upstart scripts OR to use "pre/post" commands with reentrant calls to ifupdown based on the desired order.

Any comments here are much appreciated.

Thank you

Rafael Tinoco