Bug#754121: AICCU not starting on boot in Debian
On 2016-02-26 14:56, Mark Brown wrote: > On Fri, Feb 26, 2016 at 02:17:46PM +0100, Jeroen Massar wrote: >> On 2016-02-26 13:55, Mark Brown wrote: >>> On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote: > 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". > >>> This is true for things intended to be used interactively from a UI but >>> not for everything, for example IPSEC tunnels establised with FreeS/WAN >>> can be started with just local configuration. > >> There is no external configuration for IPSEC. You just configure the >> parameters statically on both ends, and presto. > > Yes, everything is stored in local config files which does make things a > easier to implement. Thus, how would you do it when that is not the case? >>> The UI presented for >>> AICCU is much more that of a daemon than of a GUI or something designed >>> to tie into ifup/ifdown type scripting. It's really not obvious how to >>> robustly start AICCU in a way that fits well with the UI as it stands, >>> the constraints it has are pretty tight. > >> Which UI? > > The way it interacts with the rest of the system and hence the user is a > UI. (I think you want to rephrase that sentence ;) It is helping: it logs an error message stating you to fix your network. > >>> Compared to other system daemons this is highly unusual behaviour, I >>> think this is my main point - there's a conflict between the interface >>> presented and the error handling. > >> Since when is reporting an error in the logs unusual for a daemon? > >> Which "interface" are you exactly talking about? > > Reporting errors via logs is not unusual. Exiting when confronted with > transient runtime errors is much more unusual. AICCU does not know that the problem is 'transient' or 'persistent'. Only a human knows this is the case and how to resolve the problem. Make a typo in nginx, apache etc config, they will all bail out as they cannot resolve it either. Same situation: broken configuration -> log & exit. That is the model that AICCU operates under as it is one that makes sense. Keeping on retrying does not resolve anything and just makes things magic. Your logs will love being spammed with that amount of activity. > >>> If it tries and/or logs excessively then sure. This is a readily >>> solvable problem though. > >> How is such a thing solvable? Are you going to suppress some but not all >> messages? > > That's one option but I was more thinking of things like rate limiting > the activity being logged (which would be needed to avoid hammering on > the TIC, assuming we get far enough to even talk to it). Do you also rate limit these events on the other side and every hop in between of that connection? What about the router, DNS server and many other elements that are involved? As you do not know what the actual problem is, how do you know what to rate limit, or when that problem goes away? It is not a solution in any way: fix your network instead. > >>> ...and then manually kick AICCU. It's the manually kick that isn't >>> great, especially as IPv4 will recover by itself and most things will >>> fall back to IPv4 which makes the problem less obvious than it might >>> otherwise be. > >> Why is that "not great"? > > It's not a good user experience, the whole "see if the network came up > then try again" loop is something that everything else in my system > (mail, NTP, whatever) does without manual intervention. Those configurations you are talking about are static, there are no dynamic parts there. >> How would AICCU figure out otherwise that you fixed your network? > > By waiting some reasonable time period, trying again and finding things > work. You mean: keep on hammering on something, even though the real problem has not been resolved whatsoever... >> How will "IPv4 recover by itself"? > > In the case of my home network the cable modem, router and the network > end will decide they'll talk to each other again through a similar > process of monitoring links and retrying to the one I'm suggesting. All your hosts monitor all those links? How do they do that? Is that standard in Debian or for that matter any other OS? Also, every other VPN tool does that "Can't reach other side, bye bye". I am pretty sure that even more advanced UIs (Windows, OSX) towards users also nicely show "it is broken, try again later, quiting now". But they can as there the user is most very likely looking at the desktop. The problem with Linux/BSD in general is that the user is not sitting behind the screen where that warning goes. >> Is the IPv4 connectivity also provided by a VPN-alike tool? > > No (well, I'm not actually sure how VPN like cable modems are TBH - > there is some other network going on and for stuff over phone lines it > pretty much is a tunnel over the phone network,
Bug#754121: AICCU not starting on boot in Debian
On Fri, Feb 26, 2016 at 02:17:46PM +0100, Jeroen Massar wrote: > On 2016-02-26 13:55, Mark Brown wrote: > > On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote: > >> 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". > > This is true for things intended to be used interactively from a UI but > > not for everything, for example IPSEC tunnels establised with FreeS/WAN > > can be started with just local configuration. > There is no external configuration for IPSEC. You just configure the > parameters statically on both ends, and presto. Yes, everything is stored in local config files which does make things a easier to implement. > > The UI presented for > > AICCU is much more that of a daemon than of a GUI or something designed > > to tie into ifup/ifdown type scripting. It's really not obvious how to > > robustly start AICCU in a way that fits well with the UI as it stands, > > the constraints it has are pretty tight. > Which UI? The way it interacts with the rest of the system and hence the user is a UI. > >> It is helping: it logs an error message stating you to fix your network. > > Compared to other system daemons this is highly unusual behaviour, I > > think this is my main point - there's a conflict between the interface > > presented and the error handling. > Since when is reporting an error in the logs unusual for a daemon? > Which "interface" are you exactly talking about? Reporting errors via logs is not unusual. Exiting when confronted with transient runtime errors is much more unusual. > >> Your logs will love being spammed with that amount of activity. > > If it tries and/or logs excessively then sure. This is a readily > > solvable problem though. > How is such a thing solvable? Are you going to suppress some but not all > messages? That's one option but I was more thinking of things like rate limiting the activity being logged (which would be needed to avoid hammering on the TIC, assuming we get far enough to even talk to it). > >> It is not a solution in any way: fix your network instead. > > ...and then manually kick AICCU. It's the manually kick that isn't > > great, especially as IPv4 will recover by itself and most things will > > fall back to IPv4 which makes the problem less obvious than it might > > otherwise be. > Why is that "not great"? It's not a good user experience, the whole "see if the network came up then try again" loop is something that everything else in my system (mail, NTP, whatever) does without manual intervention. > How would AICCU figure out otherwise that you fixed your network? By waiting some reasonable time period, trying again and finding things work. > How will "IPv4 recover by itself"? In the case of my home network the cable modem, router and the network end will decide they'll talk to each other again through a similar process of monitoring links and retrying to the one I'm suggesting. > Is the IPv4 connectivity also provided by a VPN-alike tool? No (well, I'm not actually sure how VPN like cable modems are TBH - there is some other network going on and for stuff over phone lines it pretty much is a tunnel over the phone network, especially in the UK where the IPs all share a local loop infrastructure). > > I think some of what might be happening is that there's some noticable > > proportion of people who feel they need to restart AICCU a lot are doing > > so to work around things like transient errors on startup and are doing > > it in an unsophisticated way due to inexperience or thoughtlessness. > No, those restarts are happening become some person in a distribution > position (eg Debian, OpenWRT developers) made that decision. > The user only notices it when they are locked out though. They typically > do not read the logs... So you're saying you're having this problem as a result of distributors shipping this sort of hack rather than end users? That is very surprising I have to say. It certainly isn't Debian at present (it just tries to start once), and the wording of the warnings suggested it was more likely to be end users configuring things. > > Were the daemon to handle this in a less surprising fashion that'd most > > likely greatly reduce the number of people doing this. > Please elaborate how the daemon could handle what in what exact way. For the portion of things prior to getting a connection to the server I'd expect it to sit and retry at some reasonable interval (once every ten minutes or something off the top of my head). > How can it know that "the network is fixed"? > Is there something magic that I am not aware of? > Broken connectivity can be because of way too many reasons. Does it matter why the connectivity was failing if it starts working again? > >> This as AICCU is an implementation of a transition technology to allow > >> someone to play with IPv6 and
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-26 13:55, Mark Brown wrote: > On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote: > >> 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". > > This is true for things intended to be used interactively from a UI but > not for everything, for example IPSEC tunnels establised with FreeS/WAN > can be started with just local configuration. There is no external configuration for IPSEC. You just configure the parameters statically on both ends, and presto. > The UI presented for > AICCU is much more that of a daemon than of a GUI or something designed > to tie into ifup/ifdown type scripting. It's really not obvious how to > robustly start AICCU in a way that fits well with the UI as it stands, > the constraints it has are pretty tight. Which UI? >>> I'd argue that AICCU can do things to help. > >> It is helping: it logs an error message stating you to fix your network. > > Compared to other system daemons this is highly unusual behaviour, I > think this is my main point - there's a conflict between the interface > presented and the error handling. Since when is reporting an error in the logs unusual for a daemon? Which "interface" are you exactly talking about? >>> 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. > > If it tries and/or logs excessively then sure. This is a readily > solvable problem though. How is such a thing solvable? Are you going to suppress some but not all messages? Please note that people who do not look at logs, will never figure out that there is a statement in the logs. If there is 1 or thousands of messages. >> It is not a solution in any way: fix your network instead. > > ...and then manually kick AICCU. It's the manually kick that isn't > great, especially as IPv4 will recover by itself and most things will > fall back to IPv4 which makes the problem less obvious than it might > otherwise be. Why is that "not great"? How would AICCU figure out otherwise that you fixed your network? How will "IPv4 recover by itself"? Is the IPv4 connectivity also provided by a VPN-alike tool? >>> 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. > > No, I've seen the stuff about not hammering on the TIC. You might have seen it, but do you understand it? > The other way > of looking at this is that if there are very large numbers of users who > are trying to do this then probably there is some need that is not being > met. Very large numbers? Please remind yourself that if something gets built into something and then distributed that it automatically affects every single one of the people who automatically gets to run that code. > I think some of what might be happening is that there's some noticable > proportion of people who feel they need to restart AICCU a lot are doing > so to work around things like transient errors on startup and are doing > it in an unsophisticated way due to inexperience or thoughtlessness. No, those restarts are happening become some person in a distribution position (eg Debian, OpenWRT developers) made that decision. The user only notices it when they are locked out though. They typically do not read the logs... > Were the daemon to handle this in a less surprising fashion that'd most > likely greatly reduce the number of people doing this. Please elaborate how the daemon could handle what in what exact way. > Probably there are other people doing this for reasons I can't think of > right now of course but I'd not be surprised if they were in the > minority. Probably there are people who want to have a pony. Without actually describing what the problem is, and how something can be properly resolved, there is really little to state about things. >> 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. > > It can't fix the network by itself, no. It can recover when the network > is fixed though. How can it know that "the network is fixed"? Is there something magic that I am not aware of? Broken connectivity can be because of way too many reasons. >> And in the end. more importantly: > >> Did you call your ISP for native IPv6? > > Yes, not in this particular campaign but recently enough. I'd actually > be fairly happy with a commercial VPN service but can't seem to find one > that's able to cope with dynamic IPs. Sounds you have a business case. >> This as AICCU is an
Bug#754121: AICCU not starting on boot in Debian
On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote: > 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". This is true for things intended to be used interactively from a UI but not for everything, for example IPSEC tunnels establised with FreeS/WAN can be started with just local configuration. The UI presented for AICCU is much more that of a daemon than of a GUI or something designed to tie into ifup/ifdown type scripting. It's really not obvious how to robustly start AICCU in a way that fits well with the UI as it stands, the constraints it has are pretty tight. > > I'd argue that AICCU can do things to help. > It is helping: it logs an error message stating you to fix your network. Compared to other system daemons this is highly unusual behaviour, I think this is my main point - there's a conflict between the interface presented and the error handling. > > 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. If it tries and/or logs excessively then sure. This is a readily solvable problem though. > It is not a solution in any way: fix your network instead. ...and then manually kick AICCU. It's the manually kick that isn't great, especially as IPv4 will recover by itself and most things will fall back to IPv4 which makes the problem less obvious than it might otherwise be. > > 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. No, I've seen the stuff about not hammering on the TIC. The other way of looking at this is that if there are very large numbers of users who are trying to do this then probably there is some need that is not being met. I think some of what might be happening is that there's some noticable proportion of people who feel they need to restart AICCU a lot are doing so to work around things like transient errors on startup and are doing it in an unsophisticated way due to inexperience or thoughtlessness. Were the daemon to handle this in a less surprising fashion that'd most likely greatly reduce the number of people doing this. Probably there are other people doing this for reasons I can't think of right now of course but I'd not be surprised if they were in the minority. > 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. It can't fix the network by itself, no. It can recover when the network is fixed though. > And in the end. more importantly: > Did you call your ISP for native IPv6? Yes, not in this particular campaign but recently enough. I'd actually be fairly happy with a commercial VPN service but can't seem to find one that's able to cope with dynamic IPs. > 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. It also seems like if the server side were more widely available it'd be really helpful for VPN providers. > 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. VPN tools aren't much help without something on the other end. signature.asc Description: PGP signature
Bug#754121: AICCU not starting on boot in Debian
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
Bug#754121: AICCU not starting on boot in Debian
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
Bug#754121: AICCU not starting on boot in Debian
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)
Bug#754121: AICCU not starting on boot in Debian
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
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-17 13:47, Mark Brown wrote: > Hi, > > There's a bug open in Debian about AICCU not starting when used with > systemd (though it's most likely not that specifically). One of the > last things in the bug log is: > > | Actually, a concise problem statement would be a good thing to have, as > | it seems completely lost in the bug report. > > 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. > 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. Greets, Jeroen
Bug#754121: AICCU not starting on boot in Debian
Hi, There's a bug open in Debian about AICCU not starting when used with systemd (though it's most likely not that specifically). One of the last things in the bug log is: | Actually, a concise problem statement would be a good thing to have, as | it seems completely lost in the bug report. 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. The problem seems to be that AICCU is started before the network is available (this is with the network managed via NetworkManager) and can't cope with that: Feb 17 12:19:11 slippershell aiccu[517]: Couldn't resolve host tic.sixxs.net, service 3874 Feb 17 12:19:11 slippershell aiccu[517]: Couldn't connect to the TIC server tic.sixxs.net Feb 17 12:19:11 slippershell aiccu[517]: Couldn't retrieve first tunnel for the above reason, aborting 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. Restarting after boot does seem to work perfectly happily, it's just the above issue. I'm guessing that this is what the ifup.d script that was there in earlier package versions was intended to fix. Thanks, Mark signature.asc Description: PGP signature
