Package: ifupdown Version: 0.6.7 Severity: normal
On a host with a bridge configured, ifdown may hang indefinitely waiting for the bridge to be deconfigured if called as `ifdown -a'. This appears to happen because the loopback device is bought down before the bridge, and the bridge code doesn't cope with that. Manually bringing down the bridge, then the loopback interface, works correctly. It looks like this issue arises because ifdown brings down interfaces in the order they appear in ifstate, and ifup brings them up (and adds them to ifstate) in the order they appear in /etc/network/interfaces. However, moving `lo' to the bottom of /etc/network/interfaces won't resolve this issue, as the loopback interface must be active in order to bring up a bridge - thus it MUST always appear before the bridge in ifstate. I realise the report above is a little too close to "it doesn't work" for comfort. Unfortunately, I can't find my original notes that recorded the exact messages produced during shutdown, and I'm not willing to hang the server on shutdown again to find out. Especially given the need to sysreq-reboot it. I'll try to suppliment this report with more details later, but the info above describes the issue as I encountered it. I have successfully worked around it by adding a new init script that runs after `networking' during boot, and before it on shutdown. It'd be much nicer to be able to do this as part of ifupdown. I can think of four ways around the issue; I'm sure more are possible: The first is to to always bring down the loopback interface last, ignoring ifstate. It is not impossible that this could introduce other issues, but I'm inclined to think it'd be safe. Another alternative is to bring down interfaces in the reverse order that they appear in the ifstate file. This would seem likely to be a better solution than the first, in that it avoids the special case on `lo' and may resolve other similar problems with dependent interfaces. It's also more typical in computer software in general - things are typically deconstructed in the reverse order of their construction, a pattern that continues to appear for what are often good reasons. A third alternative is to add dependency management to /e/n/i as per: #113230: please consider adding dependencies to interfaces This places the burden on the user - providing maximum control, but plenty of room to make mistakes. I'm not sure it's a better option than just reversing the order in which ifstate is processed. A final alternative is to bring down all bridges first in `ifdown -a', then bring down other interfaces. I tend to think this is the worst of the lot, adding a potentially annoying special case (especially if you have something ELSE that is in turn dependent on the bridge). Still, it bears mentioning. Of the four ideas outlined above, I rather prefer the second based on my admittedly rather limited knowledge. It seems sensible, intuitive, and as far as I can tell it's safe. Dependency management would be a bonus, but if interfaces were bought down in reverse order to bring-up I think dependencies would only be required for bring-up - bring-down would happen in the right order automatically. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages ifupdown depends on: ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii net-tools 1.60-10 The NET-3 networking toolkit -- debconf information: ifupdown/convert-interfaces: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
