Hi Buchan,
Thanks for the response. I will disable the ntp-test. it's running on three hosts and all of them report the same WARNING-output.
However, the reason I came up with this is that in our network we have some W2K-hosts (the Domain Controllers) who have (according to Xymon) a time that is not accurate (I'm using the CLOCK option and Xymon thinks they are drifting too far; above threshold of 30 seconds).
I wondered: how is this determined on the Windows side? Because when we have a look at this system, the time is correct? It looks like the time difference between the page generation and the send time (12:38:57 - 12:37:19) = 98 seconds off (see below).
The time on the server however IS correct. I've seen it, but since the total MSG-size for these servers is so large (a few hundreds KB to 1 or 2 MB, because of the domain controller function, there are hundreds of open ports
- netstat output), it does take some addiotinal time for the Xymon client/server combination, to proces?!
Can I limit this output. For example: do NOT send UDP output? That would be a quick fix solution? Or better: split the output in several files, since the other (netstat) info is valuable, but it should NOT interfere with the normal functionality of Xymon and/of its clients. So the output should be send seperately to the server.
Regards, Peter
*Wed Nov 11 12:38:57 2009*
Wed Nov 11 12:37:19 2009 NOT ok
[image: yellow] System clock is 98 seconds off (max 30)
local: Wed Nov 11 12:37:19 2009 UTC: Wed Nov 11 11:37:19 2009
2009/11/11 Buchan Milne <bgmilne at staff.telkomsa.net>
On Wednesday, 11 November 2009 12:00:19 Peter Welter wrote:
Today, I discovered the following for the ntp-test on our Xymon server:
Service ntp on xymon is OK (up)
Command: ntpdate -u -q -p 2 132.229.84.242 2>&1
!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!The ntpdate program is deprecated and should not be used any more. To
quote the upstream ntp developers:
"The functionality ntpdate offered is now provided by the ntpd daemon itself. If you call ntpd with the command line option -q it will retrieve the current time and set it accordingly."
Please check the Network Time Protocol (NTP) daemon man page and http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate for further information.
You can replace the ntpdate call with "rcntp ntptimeset" to achieve an inital poll of the servers specified in /etc/ntp.conf.
The program /usr/sbin/sntp offers comparable functionality to ntpdate.
Except the option flags are totally different.
Specifically sntp -P no -r pool.ntp.org is equivalent to ntpdate pool.ntp.org
For further details please refer to the man page of sntp.
sntp: unable to write PID to /etc/sntp.pid sntp: Permission denied
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate#Set_the_time_before_
running_ntpd
I always thought I needed to run this ntp-test to make sure the time is correct on the central monitor server, to make sure that the time on other monitored hosts is checked correctly.
Should I
- change the NTPDATE="ntpdate"-location in /etc/hobbit/hobbitserver.cfg to NTPDATE="sntp -u" to make it work again?
This on it's own won't be enough, as additional options are added to the NTPDATE path:
$ grep -n -A7 NTPDATE ./bbnet/bbtest-net.c 991: p = xgetenv("NTPDATE"); 992- strcpy(cmdpath, (p ? p : "ntpdate")); 993- for (t=service->items; (t); t = t->next) { 994- if (!t->host->dnserror) { 995- sprintf(cmd, "%s -u -q -p 2 %s 2>&1", cmdpath, ip_to_test(t->host)); 996- t->open = (run_command(cmd, "no server suitable for synchronization", t->banner, 1, extcmdtimeout) == 0); 997- } 998- }
These options aren't supported by sntp. You could hack this by modifying the options, but the long-term fix (for people who don't have sntp yet) would have to be different.
- disable the ntp-test since because it is useless for checking the correct time on monitored hosts.
NTP is not that useful for monitoring the time on monitored hosts, (the client's built-in check is better, see the CLOCK option for hobbit-clients.cfg thresholds), unless you are running all your hosts as ntp servers. It is however useful for checking whether the host believes it should be able to provide time services to other hosts.
I only run this network test against NTP servers that other hosts use as time sources.
Regards, Buchan