> 16:58 < smoser> ie, to safeguard for the power failure case, where 5 minutes wasn't enough, but 5 minutes and 3 seconds would have been.
> 16:59 < stgraber> so we want dhclient to try for $TIMEOUT, if it gets a lease during that time, background itself and get into a renewal/retry loop, if it doesn't, then ???
> 16:59 < stgraber> for ??? I tend to prefer failing as I really don't want to run the ifupdown hooks unless we have a working connection
> 17:00 < stgraber> but you clearly prefer continuing regardless that'll make all the upstart jobs trigger as well as all upstart hooks (even though you don't have network access)
Well, I don't know that I prefer that. Sorry I didn't see that earlier.
Obviously, triggering jobs that expect network when network isn't up isn't
a great solution.
What about exiting failure after $TIMEOUT, but forking into retry loop?
On Thu, 5 Apr 2012, Stéphane Graber wrote:
> 16:58 < smoser> ie, to safeguard for the power failure case, where 5 minutes wasn't enough, but 5 minutes and 3 seconds would have been.
> 16:59 < stgraber> so we want dhclient to try for $TIMEOUT, if it gets a lease during that time, background itself and get into a renewal/retry loop, if it doesn't, then ???
> 16:59 < stgraber> for ??? I tend to prefer failing as I really don't want to run the ifupdown hooks unless we have a working connection
> 17:00 < stgraber> but you clearly prefer continuing regardless that'll make all the upstart jobs trigger as well as all upstart hooks (even though you don't have network access)
Well, I don't know that I prefer that. Sorry I didn't see that earlier.
Obviously, triggering jobs that expect network when network isn't up isn't
a great solution.
What about exiting failure after $TIMEOUT, but forking into retry loop?