On 2016-02-17 19:26, Mark Brown wrote: > On Wed, Feb 17, 2016 at 05:46:53PM +0100, Jeroen Massar wrote: >> On 2016-02-17 17:00, Mark Brown wrote: > >>> Right, but I do think AICCU can deal better with this situation. Not >>> dealing with it makes system integration much harder as there are a >>> range of options that users have for configuring their network in most >>> distributions > >> Which 'options' are not properly handled? What is the real actual >> problem you are trying to solve? > > The case that is most difficult for me to eliminate in my system is that > where both the router and the modem (which are separate devices) are > being started at the same time. AICCU is running on the router, it will > most likely have a connection to the modem prior to the modem uplink > being ready. I am particularly concerned about this for unattended > boots (for example, after power loss) but it'd be nice if it worked in > general.
Sounds like you need to wait for the network to be operational before starting AICCU.... No VPN-alike tool does such a thing. OpenVPN for instance also nicely aborts as it can't do anything with that situation. SSH tunnels also nicely state "no network". >>> including off-system network connectivity like >>> routers which the distribution has little chance to integrate with). > >> You know this Internet thing, it is rather big, lots of routers are >> involved in a typical connection, only few a user has control over, let > > I am aware of this, thanks. > >> alone zero that AICCU can do anything about. > > I'd argue that AICCU can do things to help. It is helping: it logs an error message stating you to fix your network. It cannot guess what the problem is. Keeping on restarting is not the answer that will solve all the situations, and it cannot know what the situation is, or when it will be fixed. If you "only start it 5 times", it might be that your network is ready at attempt 6 or maybe very briefly at attempt 12. >>> I disagree here. While it is true that AICCU can not resolve this issue >>> for itself I think it can handle it more gracefully, it can sit and keep >>> trying so that when the situation is resolved then AICCU will recover. > >> How long should it keep on hammering on services for the situation to >> resolve itself? > > I'd expect it to try indefinitely. I'd not expect it to hammer on > things but rather to try periodically. Your logs will love being spammed with that amount of activity. It is not a solution in any way: fix your network instead. >>> This is more in line with what other services like mail servers > >> You mean a mail client (MUA) like Thunderbird I hope. > >> Guess what that does, indeed, it shows an error to the user that the >> connection fails. > >> Mail servers are a quite different kind of beast, they do not sit at a >> user end. > > I actually mean both (basically, anything that maintains a queue could > have such behaviour AICCU, nor any kind of VPN, has any kind of "queue". > - there are simple MTAs specifically designed for > centralizing the mail queue on a system, this is useful as it allows > utilities to do e-mail without requiring configuration duplication or > wheel reinvention). AICCU is not such a tool you are describing in any way or form. > The text mail clients I use use a central MTA and > just return as soon as they've handed over to it, Evolution just > silently queues things for sending at a later time unless you've started > an explicit sync operation (or did last time I checked anyway). A MUAs send directly to a MTA. That your MTA keeps on retrying is one thing, when your MUA can't reach the MTA though it will fail and state that by logging an error or presenting it. >>> or things like ypbind > >> ypbind also nicely bails out when there is no connectivity. No need to >> keep on trying something it cannot resolve. > > No, it doesn't - it will just sit there in in the background and retry > periodically. Distro init scripts will tend to wait for it to bind in > order to support other things that might want to use the binding but the > daemon itself will happily sit there. At least in the Debian case we > wait for a while and then just carry on, leaving ypbind running in the > background. The most important differentiator is that ypbind is contacting servers that you are controlling or are affiliated with. Hammering on that is fine, doing that to other people's servers is not acceptable though. >>> do - they start up, attempt to perform their >>> functions and retry if those fail. It's also more in line with what >>> happens if there is a connectivity interruption after the daemon has >>> started. > >> I'll repeat it again.... AICCU handles connectivity failures AFTER start >> (fetching the config from TIC) perfectly fine.... > > Right, and what I'm saying is that it would be much more helpful if it > were able to handle failures at startup in a similar fashion. It handles it fine: it logs an error. Like every other VPN tool does. > It is normal to do some rate limiting (eg, retry at some interval rather than > constantly) and to have options to control that behaviour for cases > where there are concerns about resource usage. You, and many others, seem to not understand that we have been trying fight people from restarting AICCU for a long time now. First because it does not resolve anything. Second, because the people do not notice anyway that it is not functional (if they did, they would check logs). The end result though is always that it keeps on hammering and hammering and hammering. And nobody will ever turn that off. Hence, why we have articles like: https://www.sixxs.net/news/2013/#tichammeringcontinuespleasecon-0722 https://www.sixxs.net/faq/aiccu/?faq=autostart https://www.sixxs.net/tools/aiccu/ (See "NOTES") https://www.sixxs.net/tools/aiccu/README and many other places which explain why it is not a good idea ever to do this. If you notice that it is does not start properly: make sure that the environment is correct for starting it in the first place. There is nothing AICCU can do about your network being broken when you try to start it. And in the end..... more importantly: Did you call your ISP for native IPv6? see also: https://www.sixxs.net/news/2015/#callyourispforipv6-1201 https://www.sixxs.net/wiki/Call_Your_ISP and various funny comments we've seen from various providers as noted on Twitter... This as AICCU is an implementation of a transition technology to allow someone to play with IPv6 and learn from it, it is not a permanent solution to get IPv6 or a static IPv6 prefix..... one day, it will all go away. Hence, if you are depending so much on it, you might want to look at native IPv6... or solving the problem for one of the many VPN tools that are out there. Greets, Jeroen
