4

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?

Improve this question
1
  • @sourcejedi I'm actually not sure whether this is debian-specific behaviour, and whether the documentation is misleading there. Anyway if you just google for a generic way to do what I want, allow-hotplug seems to be recommended way of doing it.
    – 838871
    May 23, 2019 at 12:31

2 Answers 2

Reset to default
7

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.

Improve this answer
4
  • In the bug thread they noticed a mismatch between the documentation and the actual behaviour, and that blocking the boot process is not intended behaviour regardless on how allow-hotplug should work.But using ifplugd solves my problem (it works fine for me for all combinations I tried), so I'll give you the correct answer. Also heh @ author. For anyone looking into how to configure ifplugd exactly, add eth0 to /etc/default/ifplugd's INTERFACES and remove the auto or allow-hotplug line completely from /etc/network/interfaces, keep the iface eth0 inet dhcp. Add to answer maybe?
    – 838871
    May 23, 2019 at 13:40
  • @838871 Thanks for giving your results, that's very helpful. Edited. I also left some comments on incorrect StackExchange answers, pointing them towards this one.
    – sourcejedi
    May 23, 2019 at 15:16
  • thanks for going through the lengths of not only editing and improving your answer to the current status, but also redirecting others to this solution.
    – 838871
    May 23, 2019 at 16:43
  • Thanks for noting about ifplugd; I've been using Linux distros for a long time but not so long as to have remembered those days. This really helped me with resurrecting a particularly troublesome system (a Powerbook G4). Everything is network-manager these days and it can be hard to find historical solutions or the things that used to be "common knowledge."
    – Wyatt Ward
    Jul 21, 2020 at 16:25
0

Debian also has a package for ConnMan, which is not affected by the issue you mention for NetworkManager. You might benefit from checking the common problems "Tips and Tricks" section on the Arch Wiki page, however.

On systems unlike yours, where policykit-1 is available, the upstream ConnMan can use it to selectively grant access to unprivileged users. However the Debian ConnMan package is not even dynamically linked against a policykit library. So I am not sure how access by unprivileged users is controlled.

If you did want to use NetworkManager, it seems to me the Debian package should be fixable to work without forcing you to install the policykit-1 daemon, and hence libpam-systemd and so on. You would just have to control your interfaces using sudo nmcli. Other packages e.g. udisks do not depend on policykit-1, they only recommend it. This might not be a very common desire, but if anyone else wanted it, they may as well submit a "wishlist" bug to Debian.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .