[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: Re: ntpd daemon
From: Sam Liddicott <sam () liddicott ! com>
Date: 2015-03-23 15:36:57
Message-ID: CAOj-5WAYsex298io-C1msQXuzj63xYecyZ2gXmM+QGt3-7qKeQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
>
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
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar \
5, 2015 at 1:03 PM, Denys Vlasenko <span dir="ltr"><<a \
href="mailto:vda.linux@googlemail.com" \
target="_blank">vda.linux@googlemail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Thu, Mar 5, 2015 at 11:43 AM, Laszlo Papp \
<<a href="mailto:lpapp@kde.org">lpapp@kde.org</a>> wrote:<br> > The problem \
is not when no peer is defined. The problem is when the<br> > peer is defined, but \
we cannot talk to it. Therefore, the issue that I<br> </span>> raised is still \
[not] addressed with regards to this.<br> <br>
This is not an easy thing to decide.<br>
<br>
If -p PEER doesn't resolve, what to do? Exit? Drop this peer?<br>
Retry? For how long?<br>
<br>
More to it. What if ntpd runs for months/years? What if PEER's<br>
IP changes? (We can't assume IP address of the server NEVER change)<br>
Do we need to re-resolve the name once in a while?<br>
<br>
Implementing any of this would require adding more code<br>
and more knobs (such as "how many retries to do"?).<br>
<br>
I decided that for now we are okay with a simplest solution.<br>
Complications can be added when a user will demonstrate<br>
a real-world case where he _had to_ fix a problem.<br></blockquote><br></div>I have a \
real use case. <br><br>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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br></div><div \
class="gmail_extra">Sam<br></div><div class="gmail_extra"><br><br></div></div>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic