$ 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