[ntp:questions] ntpq -p command query

A C agcarver+ntp at acarver.net
Thu Aug 1 20:42:19 UTC 2013

On 8/1/2013 12:46, unruh wrote:
> On 2013-08-01, detha <detha at foad.co.za> wrote:
>> On Wed, 31 Jul 2013 08:04:53 +0000, A C wrote:
>>> On 7/31/2013 00:26, Biswajit Panigrahi wrote:
>>>> But the problem I am facing is:
>>>> Whenever the connectivity between the server goes down, the status field
>>>>   will not change immediately. My observation was whenever the reach
>>>> field of ntpq -p command comes to zero then only the status field
>>>> changes. That's why I was trying to reduce the time gap.
>>>> If My approach is not correct then please suggest me the other approach.
>>> You are making it far too complex and using the wrong tool for the job.
>>>    If you want to know whether the connection between two machines goes
>>> down, use the right tool for the job.  Tools like ping and traceroute, for
>>> example, will tell you instantaneously if there is a connection problem.
>>> Use ping to probe the other server several times (assuming the other
>>> server is yours.)  If you get no response, the connection failed.
>> Ping-able network connection and a responsive ntpd on the other end is not
>> the same thing. There are devices in our network that can get time from
>> the primary NTP server, but not ping it, and vice versa. It all depends on
>> network/firewall setup.
> It tells you that at the specific time that you sent out that query,
> there was an ntpd server (not an ntp server, since not all servers are
> ntpd, and thus not all servers respond to ntpq queries). But that could
> simply be a brief aberation on the part of the network and your ntp
> client could get a return packet every time is queries around that time.
> Network disconnections can be very transient. Do you really want to
> abandona a server everytime such a blip occurs? Ssurely you want to wait
> for a few poll intervals to see if the disconnection is more than
> temporary. Otherwise on a busy network you could get huge amounts of
> trashing as you keep changing servers.

I based my suggestion on the two bits of information in the OP's initial 
statements.  The first was two local machines (presumably both under his 
control in some form) and two that he wanted to know instantaneously 
hence his desire to reduce the polling period.

So in that environment ping will work (assuming ntpd on the server 
hasn't crashed for which ping can not spot) and the polling period can 
be adjusted at will.

However, if he just wanted to test for the presence of ntpd without 
having to get the text and parse it (as detha mentioned, ntpq doesn't 
have a non-zero status return if it fails), one could use something like 
netcat with a short timeout:

nc -w 2 -z server_name_or_ip 123

This will spit out a return status value if the connection fails after 
the timeout.  If ntpd isn't there, the connection won't work and no 
parsing has to be done.

More information about the questions mailing list