>>> In article <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >>> writes:
vrkid0> Hi vrkid0> On Mar 19, 4:53 am, Harlan Stenn <[EMAIL PROTECTED]> wrote: >> Again, what exactly do you mean by "doesn't start"? >> >> >>> In article <[EMAIL PROTECTED]>, >> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >> vrkid0> Hi If it was a resolving issue than the -n switch would have vrkid0> absolved me from the problem. >> Why do you think this would matter? vrkid0> Because the -n switch means forces not to try and resolve the vrkid0> addresses and when there is resolving issues on a system using it vrkid0> avoid dealing with resolving timeouts. -n means "do not fork". I see nothing in the code about it affecting dns resolution. vrkid0> We have several Solaris and Linux servers on the same subnet with vrkid0> the same resolver (DNS) setup and none of them has the same problem. >> That does not mean there is not a problem on this one machine, however. vrkid0> True, but reduces the possibility of resolver issues to almost vrkid0> none. There isn't any firewall active on the system. Other software vrkid0> on the same system doesn't have resolver issues and works fine. I vrkid0> did another test: I changed the system network configuration to vrkid0> aquire it's setting from a DHCP server. ntpq still the same thing. What if this is an issue with the way DNS resolution is configured on the machine? That would not be affected by your network setup. vrkid0> I also noticed from my first post that ntpd failed with segmentation vrkid0> fault (running it with ntpd with -d) and it's not a hardware issue vrkid0> (as other operating system (Linux/Windows) worked on this hardware vrkid0> for months without a problem. >> Do you still have that core file? If ntpd was compiled with symbols a >> stack backtrace would be useful. vrkid0> It's not a core file. It's a system call trace file, I can vrkid0> reproduce it if someone is interesting in helping me debug the vrkid0> problem. Your call. If you want somebody to successfully help resolve the problem you need to provide the information needed to duplicate and analyze the problem. And http://bugs.ntp.isc.org is a better for that than this newsgroup, and I'm happy to work with you to better identify the problem before it makes it to the bugs page. vrkid0> I reduced ntp.conf to the bare minimum (see below) and I'm still vrkid0> experiencing the slowness on the openbsd system. >> By "slowness" you mean the delay before ntpq responds? vrkid0> Yes. 5+ minutes, regardless of ntpd running on or not. My guess is still DNS resolution issues. You may need to crank debugging and/or add debug lines to the code and/or strace (or truss or ...) the code to see what it is doing. vrkid0> Running ntpq -pn from another linux (or solaris) server on the same vrkid0> subnet returns a reply immediately. >> To the same server? vrkid0> Yes to the same OpenBSD server. Then this is still sounding like a DNS resolution problem to me. What other possibilities are there? H _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
