ntpd daemon

[Sam Liddicott]

On Thu, Mar 5, 2015 at 1:03 PM, Denys Vlasenko <vda.linux at googlemail.com>
wrote:

> On Thu, Mar 5, 2015 at 11:43 AM, Laszlo Papp <lpapp at kde.org> wrote:
> > The problem is not when no peer is defined. The problem is when the
> > peer is defined, but we cannot talk to it. Therefore, the issue that I
> > raised is still [not] addressed with regards to this.
>
> This is not an easy thing to decide.
>
> If -p PEER doesn't resolve, what to do? Exit? Drop this peer?
> Retry? For how long?
>
> More to it. What if ntpd runs for months/years? What if PEER's
> IP changes? (We can't assume IP address of the server NEVER change)
> Do we need to re-resolve the name once in a while?
>
> Implementing any of this would require adding more code
> and more knobs (such as "how many retries to do"?).
>
> I decided that for now we are okay with a simplest solution.
> Complications can be added when a user will demonstrate
> a real-world case where he _had to_ fix a problem.
>

I have a real use case.

I wasn't using ntp but msntp because I was trying to track a local time
which might not be a stable time server. Once msntp could no longer
validate the time with the local server, or the error was too great for
adjtime, it would quit, and I would re-start it from a script loop, and so
the hostname to msntp would get re-resolved.

I give this as a real world case that for long term time tracking, it is
important to be able to re-resolve the name.

However in the case that initial resolution also failed, I felt it OK to
abort; only when initial resolution AND ntp response were obtained did I
feel it worth entering the loop to attempt re-resolution when failure
ultimately occurs.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20150323/81785a14/attachment.html>