Dear Maintainer,

I run OpenVSwitch together with apt-cacher-ng, and find that
irregularly, apt-cacher-ng does not listen on all interfaces where I
want it to listen (not all - I have a BindAddress statement in my
config). The easy workaround is to re-start apt-cacher-ng after all
networking has come up, but it would be much nicer if it would start up
in such a way that it could be (configurably) made to wait for the
relevant interfaces to appear. The current situation leads to my VMs
being unable to access acng at times, which is sort of annoying.

I am unsure about how this behaviour to wait for something should be
properly implemented.


Kind regards,
--Toni++

Hallo,
* Toni Mueller [Sun, May 24 2015, 08:41:50PM]:
requirements. I used After=network.target in
/lib/systemd/system/apt-cacher-ng.service but this is only good for the
default interface handling, i.e. it's triggered as soon as any network
connectivity is present. This works ok in a regular setup where ifupdown
sets up everything in one step but not in cases like yours.

I suggest the following workaround:
$ cp /lib/systemd/system/apt-cacher-ng.service /etc/systemd/system/
$ editor /etc/systemd/system/apt-cacher-ng.service
Replace After=... with following, adapt as needed:
After=sys-devices-net-eth0.device sys-devices-net-lo.device
Reboot, reconnect and report the result. Thanks.

See also: https://bbs.archlinux.org/viewtopic.php?id=185352

Systemd makers recommend extending the particular daemons to react on
interface creation events and I will consider adding it later... maybe.

Regards,
Eduard.

Control: tags -1 + patch

If a user of libvirtd (libvirt-bin) has configured acng to listen on
the address of libvirtd's bridge (192.168.122.1 by default) so that
virtual machines can benefit from the proxy cache, then the same thing
will often happen.

I suspect that the same is true for any container/VM framework that
programmatically brings up a bridge to which containers/VMs will be
attached, such as Docker.

Instead of adding that complexity, have you considered using
IP_FREEBIND? This socket option asks the kernel to allow bind() to any IP
address, even if that address is not actually present on any device yet
(in which case there simply won't be anything to accept() from it).

Please consider the attached patch - I suspect that's much simpler than
monitoring device/address creation via netlink! I'm using the patched
version now and it seems to have the desired effect.

The only down side that I can see is that if the user has configured a
wrong BindAddress (perhaps as a result of a typo), they will no longer
get a warning in the log. If you think that's a significant problem, it
would probably be possible to adapt my patch so that it tries without
IP_FREEBIND first, and on failure, logs a warning and falls back to
retrying *with* IP_FREEBIND. I think I prefer the simpler version that
I've proposed, though.

Yes, there is no target that you can be After to represent "all services
that might programmatically bring up a bridge have done so", and in
any case it's not clear to me that it would be desirable to delay acng
startup that much - ideally I'd like acng to be already running before
libvirtd has the opportunity to start any virtual machines that might
be relying on it.

    smcv