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 (and of course network connectivity may appear and disappear at any point, including off-system network connectivity like routers which the distribution has little chance to integrate with). > > 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. 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. This is more in line with what other services like mail servers or things like ypbind 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.
signature.asc
Description: PGP signature
