Package: auto-apt-proxy Version: 18.1 $ time auto-apt-proxy Timeout occurred while waiting for network connectivity. E: Sub-process /lib/systemd/systemd-networkd-wait-online returned an error code (1)
real 0m30.149s user 0m0.013s sys 0m0.011s $ echo $? 0 $ I have an apt-cacher-ng bound to http://127.0.0.1:3142/. Earlier, auto-apt-proxy would probe the loopback address explicitly and discover this proxy. We may consider this a bug in apt-helper, but visibly it is a regression in auto-apt-proxy. $ time /usr/lib/apt/apt-helper wait-online Timeout occurred while waiting for network connectivity. E: Sub-process /lib/systemd/systemd-networkd-wait-online returned an error code (1) real 0m30.052s user 0m0.009s sys 0m0.007s $ echo $? 100 $ We may even consider this a bug in systemd-networkd-wait-online. Calling it never finishes as it runs epoll_wait with a negative timeout. I think my network configuration is sensible though maybe not common. I do not use ifupdown at all. I use systemd-networkd to manage wired network interfaces. I use iwd to manage wireless network interfaces. The timeout happens, when my connectivity is wireless and no cables are plugged. At that point networkctl identifies the wireless interface as "routable" and "unmanaged" and the wired network interface as "no-carrier" and "configuring". Reading the systemd-networkd-wait-online manual page, my understanding is that this behavior is intentional. Even setting RequiredForOnline=no for my no-carrier networks does not make systemd-networkd-wait-online finish. It will wait until at least one networkd-managed interface is routable. Arguably, this is not the event that apt or auto-apt-proxy want to wait for. It also means that reassigning the bug to systemd is unlikely to yield a satisfying result. I'm not sure where to solve this, so I'm filing it where the faulty behavior becomes visible hoping that we can better understand the interaction. Helmut
