[ntp:questions] ntp client software slow

Harlan Stenn stenn at ntp.isc.org
Mon Mar 19 21:27:06 UTC 2007

>>> In article <1174306564.003252.44160 at d57g2000hsg.googlegroups.com>, "vrkid0 at gmail.com" <vrkid0 at gmail.com> writes:

vrkid0> Hi
vrkid0> On Mar 19, 4:53 am, Harlan Stenn <s... at ntp.isc.org> wrote:
>> Again, what exactly do you mean by "doesn't start"?
>> >>> In article <1174285741.649498.183... at e65g2000hsc.googlegroups.com>,
>> "vrk... at gmail.com" <vrk... at gmail.com> 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

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?


More information about the questions mailing list