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 <st...@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 -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs