On Thu, Mar 5, 2015 at 1:03 PM, Denys Vlasenko <[email protected]> wrote:
> On Thu, Mar 5, 2015 at 11:43 AM, Laszlo Papp <[email protected]> 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
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
