[PATCH 0/2] ntpd: retry name-resolution until success

Denys Vlasenko vda.linux at googlemail.com
Thu Feb 11 11:44:58 UTC 2016

On Thu, Feb 11, 2016 at 6:05 AM, Rich Felker <dalias at libc.org> 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 <shiftee at eircom.net> 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.

More information about the busybox mailing list