FS#38221 - [aiccu] does not start on boot: treats lack of network connectivity on startup as a fatal error
Attached to Project:
Community Packages
Opened by Linus Lüssing (T_X) - Saturday, 21 December 2013, 20:19 GMT
Last edited by Sébastien Luttringer (seblu) - Saturday, 25 July 2015, 00:41 GMT
Opened by Linus Lüssing (T_X) - Saturday, 21 December 2013, 20:19 GMT
Last edited by Sébastien Luttringer (seblu) - Saturday, 25 July 2015, 00:41 GMT
|
Details
Description: On boot, aiccu tries to setup the tunnel but
fails for me because the network configuration process has
not finished yet, that is dhcpcd didn't get a DHCP lease
yet. After the DNS resolve failure aiccu exits with an error
message, resulting in the tunnel never being configured.
Furthermore, we noticed this issue because of broken internet connectivity: We had configured radvd which was announcing IPv6 default routes. As there is no notification between aiccu and radvd and since more and more websites are offering IPv6 connectivity, many applications just try IPv6 which fails due to the missing aiccu tunnel and give up after that. Additional info: * 20070115-4 This bug is the same as the one filed on the Redhat bug tracker: https://bugzilla.redhat.com/show_bug.cgi?id=844607 |
This task depends upon
I say it strongly, setting auto restart in the service file is a bad idea.
It's a complex problem. aiccu is both consumer and producer of network connectivity. So it must be launch after basic ipv4 network is up to allow ipv6 to be up.
As far I know, systemd as no helper to do that. I'll ping Tom about this.
From my current understanding, the better approach is to let the network configuration tool (NetworkManager, connman, netcfg) launch it and ensure ipv6 connectivity is up before saying network.target is reached.
In other words, using the systemd service to start the aiccu is probably a bad idea!
If network.target is not considered up until aiccu has started its tunnel an ipv6 adresse is allocated, your radvd issue should go away by using a unit like NetworkManager-wait-online.service.
FS#31846There are two options:
1. Contact with the upstream developers of aiccu, and ask them to implement a feature to wait for the network to be available, and don't fail.
2. If upstream don't want to implement it, then add the 'Wants=network-online.target' line to the aiccu.service file, and users should enable the NetworkManager-wait-online.service unit (or the equivalent unit in other network management software). This ensures that the network is configured before aiccu started.
References:
http://www.freedesktop.org/software/systemd/man/systemd.special.html#network-online.target
https://wiki.archlinux.org/index.php/NetworkManager#Enable_NetworkManager_Wait_Online
2. wait-online.target is not the real issue here! Aiccu is a network provider and consumer at the same time. This need to be handled in a network manager (connman, networkctl, NetworkManager, etc).
I guess the best solution is to drop the service file and write in wiki page how to setup it properly (by a network manager and no more by systemd directly).
That will make systemd start aiccu as soon as network access is available.
On Arch, that is the point in time, when netctl has run.
I tested this on my own box and it works flawlessly.
If a local DNS resolver is in place, a dependency on it has to be placed, too.
The original bug can be fixed by adding the following line to the Unit section of the service file.
Requires=network-online.target
The correct way to manage this, is to use a ordered network manager.
Dropping the service file is an option but I will mimic openvpn package on this (which is also comsumer and provider of networks) which is softer.