Yep, I think this is similar or the same as bug 1701023, the original vlan-ordering-ifup-call that i had to add for bug 1573272 is sometimes causing ifupdown locking issues, although ifupdown is supposed to do separate locking for each device.
Could you give that vlan pkg a try to see if it fixes this for you?
I still need to really look at and think about the locking inter-dependencies of this before trying to sru the patch, because the real question here is, will the pre-up vlan script ever get called where ifup *does* need to be run on the vlan raw-device, but the lock for that device is already held and waiting for the caller's device to come up?
Yep, I think this is similar or the same as bug 1701023, the original vlan-ordering- ifup-call that i had to add for bug 1573272 is sometimes causing ifupdown locking issues, although ifupdown is supposed to do separate locking for each device.
Anyway, I have a test fix that's similar to yours - but uses ifquery --state instead - at this ppa: /launchpad. net/~ddstreet/ +archive/ ubuntu/ lp1701023
https:/
Could you give that vlan pkg a try to see if it fixes this for you?
I still need to really look at and think about the locking inter-dependencies of this before trying to sru the patch, because the real question here is, will the pre-up vlan script ever get called where ifup *does* need to be run on the vlan raw-device, but the lock for that device is already held and waiting for the caller's device to come up?