On Thu, Feb 11, 2016 at 6:05 AM, Rich Felker <[email protected]> wrote: > On Thu, Feb 11, 2016 at 05:56:06AM +0100, Denys Vlasenko wrote: >> On Thu, Feb 4, 2016 at 2:43 PM, Mark O'Donovan <[email protected]> wrote: >> > This is an attempt to fix bug 8131: >> > ntpd: should retry on name resolving error >> >> Should it? >> Why doesn't ping do this? telnet? netcat? No network utility does this. >> Adding it to ntpd only would be inconsistent. > > Because ping, telnet, and netcat are not daemons. A daemon should > respond gracefully to transient failures rather than aborting.
In practice it is impossible to make daemons 100% robust. Because of this, we have several generations of babysitting tools which restart daemons on exit. (Some of the earliest examples are init, inetd). >> I can see why this request comes specifically for ntpd. It is often started >> early at boot. Sometimes, network isn't up for some tens of seconds >> after boot, so ntpd fails to resolve names. >> >> There are other ways to fix this. >> An utterly simplistic one would be to delay ntpd startup by, say, 20 seconds. > > That's utterly broken. You end up with an invalid or badly-wrong > clock for the first 20 seconds after boot, which could lead to all > sorts of problems with timestamps. You can't make your boot dependent on clock being set early. What if your network init always takes ~2 minutes? This is the case on my home DSL modem: DSL line training is that slow. >> A slightly better one is to restart ntpd when it fails. > > I don't see how this is any better than having it retry internally. > It's probably more work to implement and yields worse behavior. It's less code. Instead of reimplementing retries in every daemon, it's better to run them all under a babysitting tool. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
