On 8/1/2013 12:46, unruh wrote:
On 2013-08-01, detha <[email protected]> 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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
