bridge_maxwait is useless with upstart
Bug #498245 reported by
Holger Mauermann
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| munin (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned | ||
Bug Description
Binary package hint: bridge-utils
With upstart all services are started in parallel, so bridge_maxwait at its default value or set to something greater than 0 may cause some trouble... For example, I had a problem with a service not starting at boot because the address it should bind to didn't exist yet (see comment 4 in bug #442575). I had to set "bridge_maxwait 0" for both bridges in /etc/network/
Related branches
| Changed in bridge-utils (Ubuntu): | |
| importance: | Undecided → Wishlist |
| status: | New → Confirmed |
Revision history for this message
| Steve Langasek (vorlon) wrote | #1 |
| affects: | bridge-utils (Ubuntu) → munin (Ubuntu) |
Revision history for this message
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in munin (Ubuntu): | |
| status: | Confirmed → Fix Released |
To post a comment you must log in.
The specific problem you're having (from reading the other referenced bug report) is that adding the delay causes the bridge to take longer before it's brought up, and upstart doesn't wait for the bridge to finish being brought up before running the init scripts in /etc/rc2.d. However, upstart doesn't wait for *any* interfaces to be brought up before processing /etc/rc2.d, bridges or otherwise; there's a general race condition here that happens to be fixed for you when speeding up the bridge init, but solving the race generally needs to be done in the munin package:
- the munin package needs to provide an upstart job in place of the init script
- you will need to modify the upstart job to specifically wait for the bridge interface to be up ("start on net-device-up IFACE=br1") to match your specific needs of binding to a particular interface.