[Bug 548885] Re: ntp host name not found error

Bug Watch Updater 548885 at bugs.launchpad.net
Tue Oct 18 08:33:53 UTC 2011


Launchpad has imported 12 comments from the remote bug at
https://psp2.ntp.org/bugs/show_bug.cgi?id=975.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2007-12-10T01:22:40+00:00 H-murray wrote:

If DNS isn't working when ntpd starts, the lookup is deferred.

For the server command, that works correctly.  For the pool command, it only
gets 1 IP address.

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/0

------------------------------------------------------------------------
On 2007-12-10T03:52:35+00:00 Stenn wrote:

Bug 761 is kinda related to this.

If one is fixed, the other could be fairly easily fixed at the same
time.

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/1

------------------------------------------------------------------------
On 2007-12-10T04:00:37+00:00 Mayer-r wrote:

Well no. That bug doesn't deal with multiple addresses at all. The problem here
is that the pool option expects multiple addresses to be returned by DNS and
used to set up associations. That bug won't solve this one.

Danny

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/2

------------------------------------------------------------------------
On 2007-12-10T04:12:38+00:00 Stenn wrote:

Subject: Deferred DNS lookup on pool command only gets 1 server

Danny,

Well, yes.  If the response needs to be tailored, it should be pretty
trivial to knock these things out together.

I'm talking about the work that needs to be done in the forked resolver
process to get the information sent back to the main process.


-- 
Harlan Stenn <stenn at ntp.org>

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/3

------------------------------------------------------------------------
On 2009-11-18T00:37:50+00:00 H-murray wrote:

Fix is in pogo:/usa/murray/bug-975

This also fixes bug-761.

I've tested on Linus, NetBSD and FreeBSD.


Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/4

------------------------------------------------------------------------
On 2009-11-18T02:48:06+00:00 Dave Hart wrote:

I've spent a bit of time reviewing Hal's bug-975 repo.

First, above all else, Hal is cleaning house in ntp_intres.c while I'm stacking 
kindling under the corners to burn it to the ground once 4.2.6 is out.

Second, after 6 weeks in a RC cycle, is it really important to fix the bugs this 
fixes and provide the improvements this provides for 4.2.6?  A bunch of new code 
which we get to debug in -stable is unappealing to me.

Assuming you get past those concerns and proceed, other items I note:

A)  ntpd.h reverts a recent change adding const to extern char *chrootdir;
B)  ntp_intres.c has hints.ai_protocol = 17; and a comment about the header that 
value was sniped from.  That should simply come out, setting ai_protocol 
portably is nontrivial and we don't need it, do we?
C)  getaddrinfo() returning EAI_SYSTEM was retried before, now it's considered 
permanent.  If I were writing from scratch I'd do the same, but given it has 
behaved that way for years, was there a good reason to change?
D)  There are a dozen or so places where the body of an if statement continues 
on the same line as the conditional, NTP style is to put the body on the 
following line indented.
E)  In doconfigure() there's an apparently overlooked block of test code in 
column 1 under if (0) that should come out or be cleaned up to a #ifdef 
SOME_TEST_MACRO.
F)  A few lines later in doconfigure(), there's a questionable use of 
in6addr_any when returning a v4 result, which depends on whether the system was 
built with IPv6 support.  Why not use NULL as is done for the v4 address when 
returning a v6 result?

Hal, I'm troubled posting these comments.  On the one hand, I'm thrilled you've 
taken an interest in getting ntpd DNS resolution right, and you've put a lot of 
effort into developing and testing your changes.  On the other hand, well, what 
I said up top.  The timing is just horrible.  I really do want to replace 
ntp_intres wholesale with a callback-based getaddrinfo() clone that will call 
back a given function when the results are available, and that will mean most of 
your intres work will be tossed.

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/5

------------------------------------------------------------------------
On 2009-11-18T11:54:20+00:00 H-murray wrote:

Subject: Deferred DNS lookup on pool command only gets 1 server

> I've spent a bit of time reviewing Hal's bug-975 repo.

Thanks.

> First, above all else, Hal is cleaning house in ntp_intres.c while I'm
> stacking kindling under the corners to burn it to the ground once
> 4.2.6 is out.

I'm OK if we dump my stuff.  If nothing else, I think some of the quirks I've 
sorted out might be helpful.

> Second, after 6 weeks in a RC cycle, is it really important to fix the
> bugs this fixes and provide the improvements this provides for 4.2.6?
> A bunch of new code which we get to debug in -stable is unappealing
> to me. 

I don't know how to call this.  Perhaps we should move the discussion to the 
hackers list.

> Hal, I'm troubled posting these comments.

No problem from my end.  I thought they were all constructive.  Thanks.

                          On the one hand, I'm
> thrilled you've  taken an interest in getting ntpd DNS resolution
> right, and you've put a lot of  effort into developing and testing
> your changes.  On the other hand, well, what I said up top.  The
> timing is just horrible.  I really do want to replace ntp_intres
> wholesale with a callback-based getaddrinfo() clone that will call
> back a given function when the results are available, and that will
> mean most of your intres work will be tossed. 

Yup, the timing sucks.  I did it in case Harlan (and/or others) thought 
getting those bugs fixed was important enough to delay the release for more 
testing and/or take the risk.

Another possibility would be to release what we have now and plan to have 
another release as soon as some collection of changes can be tested.

> A)  ntpd.h reverts a recent change adding const to extern char
> *chrootdir; 

I think that was because I hadn't done a recent enough bk pull.  Fixed
now.

> B) ntp_intres.c has hints.ai_protocol = 17; and a comment about the
> header that  value was sniped from.  That should simply come out,
> setting ai_protocol  portably is nontrivial and we don't need it, do
> we? 

Without that, I got 3 copies of each IP Address.  One was TCP, one was UDP, I 
don't remember the 3rd.  There may be a cleaner fix, but something is needed 
in that area.

> E)  In doconfigure() there's an apparently overlooked block of test
> code in  column 1 under if (0) that should come out or be cleaned up
> to a #ifdef  SOME_TEST_MACRO. 

That's what I used to debug the above stuff.

I'm not sure how to handle code like that.  Perhaps throwing it away is best. 
 (Then we don't have to discuss it.)  That would mean somebody would have to 
type it in again if they were ever chasing the same sort of bug.  I don't 
think it's worth a macro name.  It's very localized.

Often, when I'm debugging with printfs, after I've solved the problem, rather 
than discard the debugging code, I just comment it out.  It's reasonably 
likely I'm going to want it, or something close to it, when chasing the next 
bug.  Sometimes it doubles as documentation.

Perhaps we should make OLD_DEBUG or something like that for this use.

> C) getaddrinfo() returning EAI_SYSTEM was retried before, now it's
> considered  permanent.  If I were writing from scratch I'd do the
> same, but given it has behaved that way for years, was there a good
> reason to change? 

No good reason.  It was half trying to understand things.  The "right?" in 
the old code didn't inspire confidence.  Yes, we should switch to the 
previous behavior to reduce risk.

> D)  There are a dozen or so places where the body of an if statement
> continues  on the same line as the conditional, NTP style is to put
> the body on the  following line indented. 

OK.  Where is that written up?  (I'm probably missing other similar
ideas.)

Is there code that checks for things like that?

> F)  A few lines later in doconfigure(), there's a questionable use of
> in6addr_any when returning a v4 result, which depends on whether the
> system was built with IPv6 support.  Why not use NULL as is done for
> the v4 address when returning a v6 result?

That's what the old code did.  An in6_addr is a multi word struct so I don't 
think NULL will work.

It builds with --disable-ipv6, but that's probably because I'm building on a 
system that has headers that know about IPv6 even if the ntpd won't support 
it.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/6

------------------------------------------------------------------------
On 2009-11-18T16:58:49+00:00 Dave Hart wrote:

(In reply to comment #6)
> > B) ntp_intres.c has hints.ai_protocol = 17; and a comment about the
> > header that  value was sniped from.  That should simply come out,
> > setting ai_protocol  portably is nontrivial and we don't need it, do
> > we? 
> 
> Without that, I got 3 copies of each IP Address.  One was TCP, one was UDP, I 
> don't remember the 3rd.  There may be a cleaner fix, but something is needed 
> in that area.

I'm a bit surprised, since I'd expect ai_socktype == SOCK_DGRAM would have 
excluded TCP.  Still, I was apparently wrong to say it is nontrivial to set 
ai_protocol portably, as I see ntpq and ntpdc use:

hints.ai_protocol = IPPROTO_UDP;

So that's presumably the safe choice here as well.

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/7

------------------------------------------------------------------------
On 2009-11-26T06:00:40+00:00 Stenn wrote:

Hal,

Would you please re-check this repo against ntp-dev, and discuss
this with Dave Hart (if you think that would be useful)?

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/8

------------------------------------------------------------------------
On 2009-11-26T06:11:53+00:00 Stenn wrote:

Hal,

After more reflection, I am hesitant to see a patch for this go in to
4.2.6.

I think it will be better to rewrite this code completely, after 4.2.6 is
released.

Do you have strong feelings about getting this patch in to 4.2.6?

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/9

------------------------------------------------------------------------
On 2009-11-26T07:04:30+00:00 H-murray wrote:

Subject: Deferred DNS lookup on pool command only gets 1 server

Harlan says:
> After more reflection, I am hesitant to see a patch for this go in to
> 4.2.6.

>  I think it will be better to rewrite this code completely, after
> 4.2.6 is released.

> Do you have strong feelings about getting this patch in to 4.2.6?

Nope.

I could make good arguments either way.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/10

------------------------------------------------------------------------
On 2011-10-17T17:52:34+00:00 Dave Hart wrote:

I believe this bug was fixed by 4.2.7p22 and subsequent cleanup, which
introduced both a new ntp_intres.c implementation with a callback-based
interface, and a new implementation of the pool command modelled on
manycast.

Thanks for your work on the alternative 4.2.6 patch, Hal.

Reply at: https://bugs.launchpad.net/ntp/+bug/548885/comments/20


** Changed in: ntp
       Status: Unknown => Fix Released

** Changed in: ntp
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/548885

Title:
  ntp host name not found error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ntp/+bug/548885/+subscriptions



More information about the Ubuntu-server-bugs mailing list