Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
Control: tags -1 + pending On Sun, 25 Sep 2016 17:31:23 -0400 manul wrote: > Package: ifupdown > Version: 0.8.16 > Severity: normal > > Dear Maintainer, > > My laptops cable interface eth0 is listed in /etc/network/interfaces, using > the following stanza: > > >> allow-hotplug eth0 > >> iface eth0 inet dhcp > > The reason I use allow-hotplug is: > > As per man interfaces 5, I want my eth0 interface to be brought up (and > dchp-initialized) only when the link gets up (cable gets connected). > So in a typical situation when I reboot with eth0 cable unplugged, waiting > for link initialization does not block the bootup process until timeout. > > However since recent update, ifupdown sysvinit script seems to have started > ignoring this stanza and attempts to bring up interfaces listed as > allow-hotplug in /etc/network/interfaces at boot, even if they are unplugged > (cable not connected). > > > Outcome: > > When I boot with eth0 cable unplugged in the bootup log sequence I get: > >> Configuring network interfaces... > >> ifup: waiting for lock on /run/network/interfaces/ifstate.eth0 > > At this point the boot is stuck for about 1 min until the message "ifup: > interface eth0 already configured" comes up, and bootup continues. > > > Expected outcome: > > Upon boot with cable unplugged (link state down), interfaces listed as > allow-hotplug should not be brought up/ initialized. ... This commit already in the master branch addresses the issue: https://salsa.debian.org/debian/ifupdown/-/commit/c25a05a79da5bb4f8fdc81c830f5b9624b462a06 -- Santiago signature.asc Description: PGP signature
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
Dear Maintainer, The bug still persists on fresh stretch and buster installations. Is there any chance this could get fixed, or could you close this bug with a wontfix and give a reason on why it's not? Seeing that the bug persists for 3 years now. Thank you. Information for other people running into this problem: For a configuration in /etc/network/interfaces: allow-hotplug eth0 iface eth0 inet dhcp The boot process is blocked with this message: configuring network interfaces... ifup: waiting for lock on /run/network/ifstate.eth0 One workaround seems to be to change allow-hotplug to auto, however, this makes the boot process block when no cable is plugged in, just before the tty login, because dhclient tries to get a DHCP answer and waits for several attempts to timeout. This might be irrelevant when you have an auto-starting graphical desktop environment, because that just hides the dhcp messages and you don't need a tty login on tty1. Another workaround might be to use network-manager. Not tried so far, as it conflicts with other packages on my setup. Related forum thread (in spanish): https://exdebian.org/foro/ifupwaiting-lock-runnetworkifstateeth0
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
I confirm the bug. I have a laptop and usually I use WLAN instead of cable connection. In such a case booting process stops for a few minutes with a statment "ifup: waiting for lock on /run/network/interfaces/ifstate.eth0". Dear Maintainer, could you, please, revert to previous behavior?
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
Package: ifupdown Version: 0.8.16 Severity: normal Dear Maintainer, My laptops cable interface eth0 is listed in /etc/network/interfaces, using the following stanza: >> allow-hotplug eth0 >> iface eth0 inet dhcp The reason I use allow-hotplug is: As per man interfaces 5, I want my eth0 interface to be brought up (and dchp-initialized) only when the link gets up (cable gets connected). So in a typical situation when I reboot with eth0 cable unplugged, waiting for link initialization does not block the bootup process until timeout. However since recent update, ifupdown sysvinit script seems to have started ignoring this stanza and attempts to bring up interfaces listed as allow-hotplug in /etc/network/interfaces at boot, even if they are unplugged (cable not connected). Outcome: When I boot with eth0 cable unplugged in the bootup log sequence I get: >> Configuring network interfaces... >> ifup: waiting for lock on /run/network/interfaces/ifstate.eth0 At this point the boot is stuck for about 1 min until the message "ifup: interface eth0 already configured" comes up, and bootup continues. Expected outcome: Upon boot with cable unplugged (link state down), interfaces listed as allow-hotplug should not be brought up/ initialized. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ifupdown depends on: ii adduser 3.115 ii init-system-helpers 1.45 ii iproute2 4.6.0-4 ii libc62.24-3 ii lsb-base 9.20160629 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.5~b1-1 Versions of packages ifupdown suggests: ii ppp 2.4.7-1+3 pn rdnssd -- no debconf information
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
On Sun, Sep 25, 2016 at 05:31:23PM -0400, manul wrote: > As per man interfaces 5, I want my eth0 interface to be brought up (and > dchp-initialized) only when the link gets up (cable gets connected). Actually, the manpage does not mention that hotplug interfaces are brought up only when a link is detected, only that a subsystem initializes the interface. The problem is that link detection doesn't work reliably on many network cards, and it actually caused problems in some cases. This is why I decided to make it behave more consistently, by removing the check for the link state. > When I boot with eth0 cable unplugged in the bootup log sequence I get: > >> Configuring network interfaces... > >> ifup: waiting for lock on /run/network/interfaces/ifstate.eth0 > > At this point the boot is stuck for about 1 min until the message "ifup: > interface eth0 already configured" comes up, and bootup continues. Hm, that is interesting, it shouldn't wait for the lock on eth0 there, since it's not an auto interface. I'll try to fix this at the very least, and see if I can add an option to bring back the link state detection. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
Package: ifupdown Version: 0.8.16 Followup-For: Bug #838871 First of all, I'm seeing exactly the same symptoms. One problem with not looking at link state is that the interface is always powered up. As I understand it, on some laptops this can make a measurable difference. My own measurements are a bit inconclusive (powertop reports that eth0 uses 0.3W more with ifupdown 0.8.16 than with 0.8.13, but total battery drain seems to be the same), but I believe it's a good argument for providing a link state option anyway. Apart from that, clarifying (in the documentation) what "hotplug" actually means would be good. I think your definition of "the device appears" is entirely reasonable, but these things are confusing and it's unfortunate that the concepts of "the device is there" and "the cable is there" have been mixed up historically. Frank -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ifupdown depends on: ii adduser 3.115 ii init-system-helpers 1.45 ii iproute2 4.6.0-4 ii libc62.24-3 ii lsb-base 9.20160629 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.5~b1-1 Versions of packages ifupdown suggests: ii ppp 2.4.7-1+3 pn rdnssd -- no debconf information
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
On Thu, Sep 29, 2016 at 10:28:20AM +0200, Frank Gevaerts wrote: > One problem with not looking at link state is that the interface is always > powered up. As I understand it, on some laptops this can make a measurable > difference. My own measurements are a bit inconclusive (powertop reports > that eth0 uses 0.3W more with ifupdown 0.8.16 than with 0.8.13, but total > battery drain seems to be the same), but I believe it's a good argument for > providing a link state option anyway. It already has to power up the interface before it can check the link. So there should be no difference in link power. The only difference is that dhcp is always started now, which sends packets once in a while, so that might make a tiny bit of difference. > Apart from that, clarifying (in the documentation) what "hotplug" actually > means would be good. I think your definition of "the device appears" is > entirely reasonable, but these things are confusing and it's unfortunate > that the concepts of "the device is there" and "the cable is there" have > been mixed up historically. I will add some clarification. Note that the check for the link state has not always been there, and in any case was only done at boot time. It never supported the case where there was no cable connected at boot, and where you plugged in the cable at a later time. From the changelogs, I see the main reason for adding this check for the link state was to get rid of delays during boot. So I will focus on having that go away. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
