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

List:       busybox
Subject:    Re: ntpd peer name resolution behavior
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2010-11-28 1:10:23
Message-ID: 201011280210.23453.vda.linux () googlemail ! com
[Download RAW message or body]

On Friday 19 November 2010 02:40, Justin Maggard wrote:
> Hi,
> 
> I was using the busybox implementation of ntpd, and I noticed
> something I found odd.  If I list multiple peers on the command line,
> and any one of those peers fails name resolution, ntpd immediately
> quits.  It seems to me that ntpd should not quit if we get a
> successful name resolution for at least one of the peers.  I've
> attached a patch to change this behavior, and I hope you'll consider
> it for the next busybox release.

+	p->p_lsa = host2sockaddr(s, 123);
+	if (!p->p_lsa) {
+		free(p);
+		return;
+	}

You basically drop those PEERs from -p PEER options
which have a name resolution problem.

But the resolution problem can be _temporary_.
Say, at the bootup DNS resolution may be not yet
setup correctly, and you can end up with
the situation where ntpd -p P1 -p P2
does not talk to P1 just because _at the time of startup_,
P1 name was not resolving yet.

The better fix would be to log the error, remember the hostname,
and then try to resolve it later.

(Another possibly useful feature would be to periodically
re-resolve even those names which did resolve successfully.
OTOH, with round-robin mapped ntp servers it would be bad...)



This part is wrong:

+	if (!G.ntp_peers)
+		xfunc_die();

it makes it impossible to run "peerless" ntpd server via "ntpd -l"
with n -p PEER options at all.

-- 
vda
_______________________________________________
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]