Debian workaround 838871: dhcp network configuration without blocking boot process

debiandhclientdhcpnetwork-interfacenetworking

Is there a workaround for Debian Bug #838871?

Problem: I want to have a network configuration on Debian with the following properties:

  • Automatically ifup network interface when a cable is plugged in
  • boots without blocking for a long time when no cable is connected on boot
  • not switching my init system

The standard way to do this would be the following snippet in /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp

However, this leads to the problem described in the linked bug report: The boot process blocks for >1min when no network cable is plugged in with the following message:

configuring network interfaces... ifup: waiting for lock on /run/network/ifstate.eth0

A workaround given in this question seems to be changing allow-hotplug to auto:

auto eth0
iface eth0 inet dhcp

This effectively makes the boot blocking message disappear, however, the system now blocks right before a login prompt is shown at tty1. This time dhclient is blocking because it tries to get a dhcp reply on eth0, which is not connected, and waits for several attempts to timeout. The login prompt only appears after the dhclient timeouts.

For users with a graphical DE, this might not be a problem, as they don't need to log in on tty1, instead their DE boots and they never see the dhclient message.

Another workaround would probably be to use network-manager. Ideally, I would prefer to not use networkmanager, but as a last resort, I tried that. However, on Debian buster, network-manager's dependency chain conflicts with sysvinit-core, which is my init system.

The last alternative which comes to my mind is to not configure eth0 in interfaces(5). This makes all boot blocks go away, however, I need to manually ifup eth0 after plugging in an ethernet cable.

Any better ideas?

UPDATE: To address the quote from @sourcejedi, "allow-hotplug" is specified to "start interface when the kernel detects a hotplug event from the interface" in the Debian docs under Debian networking. Related questions: Good detailed explanation of /etc/network/interfaces syntax? and What is a hotplug event from the interface?

Best Answer

Before network-manager, the well-known way to "automatically ifup the network interface when a cable is plugged in" was ifplugd. (Note the original author :-P). ifplugd is still available in Debian. I do not have any recent experience with it.

Firstly, you would remove the auto eth0 or allow hotplug eth0 line from /etc/network/interfaces. You would still need your line iface eth0 inet dhcp. (This line depends on what the name of your network interface is, and also if you want to add ipv6 support, etc).

To configure ifplugd to bring up the interface, edit /etc/default/ifplugd to set INTERFACES= to include the name of your network interface. Alternatively, it suggests you could use the value auto. I do not know how well auto works on any recent system :-).

https://manpages.debian.org/buster/ifplugd/ifplugd.conf.5.en.html


This feature was never provided by allow-hotplug:

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. -- Message #20

The sources which contradict this are just wrong. If you want this feature, you need to run a daemon which waits for "netlink" events.[*] The Debian ifupdown package does not include any daemon. allow-hotplug relies on the udev daemon, which does not read the necessary netlink events.

The udev daemon only reads udev "hotplug" events ("uevent"s). There is no "uevent" when an Ethernet device detects a link status change. You can verify this using udevadm monitor.

The Linux kernel developers made a deliberate decision not to provide a "uevent" for this. See: Re: Q: netdev: generate kobject uevent on network events.


[*] Pedant: technically ifplugd works by polling the link status at regular intervals. So it does not necessarily rely on "netlink" events. This distinction is pointed out by netplug, which does use "netlink" events. netplug does not have all the same features as ifplugd.

Related Question