On 2016-02-17 17:00, Mark Brown wrote: > On Wed, Feb 17, 2016 at 04:03:22PM +0100, Jeroen Massar wrote: >> On 2016-02-17 13:47, Mark Brown wrote: > >>> Let me try to provide that... We now no longer have the problems in the >>> original report with the boot hanging but we still don't have AICCU >>> coming up reliably at boot. > >> You should start AICCU when you have proper connectivity (time synced, >> DNS resolving works, and you can actually can make connections outbound). > >> Doing it to early is not the way to do it. > >> This is not something that AICCU can do, as it does not know when your >> system is "connected to the Internet", only the user behind the machine >> knows this. > > 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? > (and of course network connectivity may appear and > disappear at any point Network connectivity disappearing and coming back is fine. AICCU only needs connectivity at the start to fetch the configuration from TIC, after that, connectivity can go and come again. > 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 alone zero that AICCU can do anything about. >>> There's probably some init based fix for this but I'd also expect AICCU >>> to handle this more gracefully by retrying resolver failures, it seems >>> like this is something that is reasonably likely to happen during the >>> startup process. > >> As AICCU cannot resolve your DNS issue and only an administrator of the >> machine, or the DNS service, or the connectivity provider etc can, AICCU >> cannot resolve this and thus restarting it or letting it retry does not >> resolve the problem. > > 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? > If nothing changes the user is no worse off, and if the external factors > that were causing connectivity issues are resolved then things will > start working. There are MANY reasons why keeping on trying will not resolve anything and make things actually worse. Filling up a log with connection attempts will not solve it. Using CPU time that is not needed Making repeated DNS requests even though there is no connectivity (especially fun when people pay for connectivity) The user will finally notice that connectivity is not working and they will fix the real problem 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. > or things like ypbind ypbind also nicely bails out when there is no connectivity. No need to keep on trying something it cannot resolve. > 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.... Greets, Jeroen (who loves it *ahum* how often he has to repeat these statements....)
