> Jeroen, his upstart job does not use the 'respawn' keyword, so it will not be > "automatically restarted" like daemontools does. > This is only started when there is a real network interface (something I > would think necessary for this daemon to work!), > and stopped when the system is going down.
I agree that bringing the daemon up when the network goes up is fine, and as there is a PID file it will only run once and not start again when the interface is brought up again. Stopping it when the network goes down though will mean that when the network is flipping (which we have seen at several people already) you will be effectively start/stopping the daemon all the time. >From another reply: > I cannot find any documentation that indicates AICCU has any purpose other > than setting up and tearing down AYIYA tunnels. You might want to start at reading the wikipedia article which already tells you a lot more than that. It does TIC first to retrieve the tunnel configuration, then it can set up a static (which is quite useless on debian due to the great interfaces(5) :) and of course then run a heartbeat or do AYIYA. > There is no need for such a tool to run if there is no network connection, unless the tool also monitors network connectivity. The whole point of heartbeat and AYIYA is handling dynamic tunnels. > At least on my Natty system, the aiccu daemon simply terminates when no network connection is present, It exits because it is unable to retrieve the configuration. See the log file for a nice message. > so it does not appear to have any ability to monitor the status of the system's network connectivity When it is started and it can connect to the TIC server and retrieve it's configuration, then it will nicely inform the PoP of network connectivity state using either the heartbeat or the AYIYA protocol. > (and it probably shouldn't have that ability--that's really the system administrator's concern). People who are using AICCU don't care about this, they just want working connectivity and that is what it does. > So again, I would be interested to know what function of AICCU makes it useful without a network connection. Without a network connection (and with that an "Internet connection" not a local network) there is not much it can do, that is why it then also exits. When you though start it when you have working connectivity you can keep it running, no need to exit it, and it won't exit then by itself either. > I have in fact read the warning you mention. I'd be interested to know how it applies to my Upstart script and not the one on which Lars Dursig has been working on. See the above, you are also disabling it when the network goes down, as such, if the interface flips, it will Note also that there is no clause anywhere that when that interface goes up/down is actually an interface that can do anything with internet connectivity. Maybe at least a notion of a check that there is a default route would be sane to have? > Jeroen, his upstart job does not use the 'respawn' keyword, so it will not be "automatically restarted" like daemontools does. As Lars said also, it will seem to automatically restart when the network goes mad, this is something that we have seen at several people already, who nicely got a reminder to not effectively attempt to DoS the TIC server. In summary: at network-up time (for a network that actually has connectivity to the TIC server and the PoP) it is fine, but at network- down time it would be quite annoying. The annoying part comes to the user who will get emails, and the SixXS staff who will get silly complains that they had an issue, those issues you will never see here in the ticket tracker though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/223825 Title: aiccu init.d script will race dhclient (upstart issue?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
