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. > > 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. > > 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. > > 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 - 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). 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). > > 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. > > 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 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.
signature.asc
Description: PGP signature
