[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: ntpd daemon
From:       Laszlo Papp <lpapp () kde ! org>
Date:       2015-03-05 13:16:03
Message-ID: CAOMwXhNuXdEoZYG5Y2G3xNz3aptnW2S4Mo4pXYAxgKrgqvT+yQ () mail ! gmail ! com
[Download RAW message or body]

On Thu, Mar 5, 2015 at 1:03 PM, Denys Vlasenko <vda.linux@googlemail.com> wrote:
> On Thu, Mar 5, 2015 at 11:43 AM, Laszlo Papp <lpapp@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.

This is not at all what I am referring to. I am not talking about how
it ought to work. I am talking about it should be _documented_ how it
works.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]