Comment 14 for bug 1058883
Revision history for this message
| Caleb Callaway (enlightened-despot) wrote Re: [Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend | #14 |
On Fri, Oct 5, 2012 at 9:48 AM, Jeroen Massar <email address hidden> wrote:
> > When the daemon starts, it will terminate if it cannot contact the
> tunneling service
>
> At failures it will always log the error and terminate. This as that is
> the way that a user will notice things and start looking into logs.
> Unfortunately people seem to think that everything needs the Win95
> treatment and just restart things instead.
>
> >, which is very different from how the
> > daemon behaves once it's started, where it is supposed to handle network
> outages gracefully, without a restart.
>
> That is correct, but how is that inconsistent?
>
> > This bug report contains logs that illustrate the behavior:
> https:/
> > The same behavior is present on my system running a fully patched Ubuntu
> 12.04 release.
>
> That shows as the first line indicates that somebody decided to change
> the startup method which then caused things to break as there was no
> network yet. Simple solution: start it (once, btw, and not repeatedly)
> when your network connectivity is up.
>
> > These inconsistencies
>
> That is not inconsistent. If there is an error condition (broken time,
> no network) it exits.
>
> Now, if your IP address changes while it is already running, then it
> will keep on working.
>
The inconsistency is in the daemon sometimes treating a lack of network
connectivity as an error condition, and sometimes treating it as part of
normal operation (as you said previously, the daemon should _not_ restart
on resume, even though network connectivity might be lost).
I'm not sure the "loud" failure that occurs when the daemon starts without
network connectivity is worth the inconsistency, since a user is very
likely to notice the lack of connectivity in other ways (e.g. can't connect
to IPv6 sites, ping6 failing, and the sixxs interface missing from the
ifconfig output). This is very much a design decision, of course, but I'm
not sure it's optimal (see below for further reasons related to init system
concerns).
>
> > Neither aiccu's built-in behavior or the Upstart
>
> Please note that Upstart is something from Ubuntu etc, do not start
> blaming AICCU for the way that that start script handles it.
>
I do not know how assigning blame is related to the words I wrote. They
simply state that neither piece of software was capable of correctly
handling the described scenario without user intervention.
>
> > (recall the Upstart script looks for the local-file-system signal in
> addition to the net-device-up signal).
>
> Then fix upstart.
>
It's probably quite possible to address the scenario using Upstart, but it
is not a good idea to say the init system is responsible for addressing the
scenario I've described. If init systems must handle such edge cases,
systemd would have to implement a separate, incompatible method for
detecting this scenario, which duplicates effort and leads to
implementation-
violates the principle of not repeating ourselves (I'm sure you have
special appreciation for DRY after the number of times you've had to say
aiccu shouldn't be restarted).
Also, init systems like System V don't support event-based startup, so
distros that use System V are in fact incapable of handling such scenarios
with the init system.
>
> > Seems to me the best solution to these issues is for the aiccu daemon
> to behave the same way on startup and while running.
>
> As it retrieves it's primary configuration details using TIC, it needs
> them, in it's current incarnation it will thus properly exit.
>
What daemon configuration details are retrieved using TIC? Obviously the
_tunnel_ configuration details requires TIC, but I can't imagine what
details of _daemon_ configuration would require the _Tunnel_ Information
and Control protocol (emphasis is mine).
>
> > Given the choice, I'd vote for handling network outages gracefully in
> both scenarios: this makes the startup scripting very
> > simple: start aiccu on boot, and let it handle everything from there.
>
> This is what will be likely the case in the next AICCU version, which I
> want to finish but do not get around to unfortunately, maybe tomorrow
> will be the right day though....
>
I am happy to help test the next version, where can I find the source code?
The AICCU downloads page doesn't seem to have any relevant links.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> start-on conditions in Upstart script prevent aiccu from restarting
> during resume from suspend
>
> To manage notifications about this bug go to:
> https:/
>