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.
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_r...
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?
disable the ntp-test since because it is useless for checking the correct time on monitored hosts.
Regards, Peter
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
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
In <200911111352.18786.bgmilne at staff.telkomsa.net> Buchan Milne <bgmilne at staff.telkomsa.net> writes:
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.
Sorry, but I don't agree.
The CLOCK option works by comparing the timestamp a client puts into the client-message with the timestamp on the Xymon server by the time that client-message is received. This can easily vary several seconds, depending on
- the load of the Xymon server
- network latencies between the client and the Xymon server
- the load on the client
- how long it takes the client to generate the client data
- how well time is synchronized on the Xymon server
- and probably something else
That's why the default threshold for the CLOCK test is 30 seconds; it really is not a very accurate way of determining the actual time difference between a client and the "real" time.
And for some types of servers (notably Windows domain controllers and other Kerberos-style servers) it is completely inadequate.
You're right that it requires some code-changes to use the "sntp" utility instead of "ntpdate". I'll merge some code for this into 4.3.0, that will also allow us to drop the old "ntpstat" extension since we already have that data from either ntpdate or sntp.
Regards, Henrik
I just migrated from BB to xymon in the past days and didnt hit any problems while migrating. But if you done the migration, you see the options xymon offers and you want to use them :)
Were using scripts to get statuses of some hosts, like diskspace usage, mysql replication status, raid status, memcached-stats and also the amount of queued mails.
I want to have a graph that shows up the mailq status.
If done the following already:
hobbitserver.cfg Added mailq=ncv to TEST2RRD Added NCV_mailq="mailq:GAUGE"
GRAPHS=" ..,ncv, .. " is set.
hobbitgraph.cfg
[mailq] TITLE Mailqueue YAXIS Anzahl DEF:mailq=mailq.rrd:mailqueue: AVERAGE LINE2:mailq#00CCCC:mailq:AV COMMENT:\n GPRINT:mailq:LAST:Inode cache \: %5.1lf%s (cur) GPRINT:mailq:MAX: \: %5.1lf%s (max) GPRINT:mailq:MIN: \: %5.1lf%s (min) GPRINT:mailq:AVERAGE: \: %5.1lf%s (avg)\n
Im really unsure about this .. but an "hobbitgraph ncv:mailq" Link is displayed in the page of the service at my testing host.
But, and that would be the problem, there ist no .rrd file created in $HOME/data/rrd/HOSTNAME .There are only .rrd files for test which are excecuted by the xymon server, but i excecute the tests at the hosts and sending the status to the server via the bbrother.pl script.
How can i tell xymon to create the .rrd file for this test?
2009/11/13 Henrik Størner <henrik at hswn.dk>:
In <200911111352.18786.bgmilne at staff.telkomsa.net> Buchan Milne <bgmilne at staff.telkomsa.net> writes:
And for some types of servers (notably Windows domain controllers and other Kerberos-style servers) it is completely inadequate. For this reason I've set the CLOCK option to 700 seconds for these particular hosts.
You're right that it requires some code-changes to use the "sntp" utility instead of "ntpdate". I'll merge some code for this into 4.3.0, that will also allow us to drop the old "ntpstat" extension since we already have that data from either ntpdate or sntp.
Thanks for the information; that would be nice.
regards Peter
participants (4)
-
bgmilne＠staff.telkomsa.net
-
devnull＠ehwat.de
-
henrik＠hswn.dk
-
peter.welter＠gmail.com