- Xymon - Xymon mailman web

Should a HTTP 304 response be green or yellow?
by beckert＠phys.ethz.ch 06 Oct '15

06 Oct '15

Hi, one our HTTP checks went yellow today because the Apache being tested responded with a "304 Not Modified" HTTP code, and the check went yellow. "304 Not Modified" is generally a valid HTTP answer which does not indicate a problem but rather a properly working server -- if the client provided the according meta information, namely either the If-Modified-Since or If-None-Match HTTP headers. But xymonnet doesn't seem to send either of them, at least according to a quick grep through the xymon's source code. So I think that if xymonnet receives a 304 reply, there must be something wrong on the server side (broken reverse proxy or similar), hence the yellow state is some kind of justified. What do others think about that topic? Kind regards, Axel Beckert -- Axel Beckert <beckert at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/

2 1

Status, NCV and time stamps
by dboldt＠usgs.gov 06 Oct '15

06 Oct '15

I'm in the process of converting Big Brother tests to XYMon and would like to enable RRD/graphics for these tests. Several of these tests present date/time information which is important. As a workaround for one test I have replaced the colon on a HH:MM:DD formatted date with a dot, but it doesn't really look like a time anymore. * Is there a way to have NCV ignore colons (and only use "=")? * Is there a way to have NCV ignore a line (which might contain colons)? * Can I use Data messages in such a way that the corresponding Status message is not parsed? * Might there be some other mechanism entirely? -- -- David Boldt <dboldt at usgs.gov> "Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of." --Douglas Adams (1952 - 2001), Arthur Dent in "The Hitchhikers Guide to the Galaxy"

3 4

buffer overflow detected in xymongen (4.3.21)
by beckert＠phys.ethz.ch 06 Oct '15

06 Oct '15

Hi, today our xymongen check went purple for about an hour. In the xymongen.log I found tons of crash reports like this one: *** buffer overflow detected ***: xymongen terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x731ff)[0x7f31a13fc1ff] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f31a147f4c7] /lib/x86_64-linux-gnu/libc.so.6(+0xf46e0)[0x7f31a147d6e0] xymongen[0x40d526] xymongen[0x403b72] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f31a13aab45] xymongen[0x40510c] ======= Memory map: ======== 00400000-00445000 r-xp 00000000 fd:00 151583 /usr/lib/xymon/server/bin/xymongen 00644000-00645000 r--p 00044000 fd:00 151583 /usr/lib/xymon/server/bin/xymongen 00645000-00647000 rw-p 00045000 fd:00 151583 /usr/lib/xymon/server/bin/xymongen 00647000-00658000 rw-p 00000000 00:00 0 01ea3000-022fe000 rw-p 00000000 00:00 0 [heap] 7f31a0c26000-7f31a0c3c000 r-xp 00000000 fd:00 524307 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f31a0c3c000-7f31a0e3b000 ---p 00016000 fd:00 524307 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f31a0e3b000-7f31a0e3c000 rw-p 00015000 fd:00 524307 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f31a0e3c000-7f31a0f68000 rw-p 00000000 00:00 0 7f31a0f68000-7f31a0f80000 r-xp 00000000 fd:00 535294 /lib/x86_64-linux-gnu/libpthread-2.19.so 7f31a0f80000-7f31a117f000 ---p 00018000 fd:00 535294 /lib/x86_64-linux-gnu/libpthread-2.19.so 7f31a117f000-7f31a1180000 r--p 00017000 fd:00 535294 /lib/x86_64-linux-gnu/libpthread-2.19.so 7f31a1180000-7f31a1181000 rw-p 00018000 fd:00 535294 /lib/x86_64-linux-gnu/libpthread-2.19.so 7f31a1181000-7f31a1185000 rw-p 00000000 00:00 0 7f31a1185000-7f31a1188000 r-xp 00000000 fd:00 535286 /lib/x86_64-linux-gnu/libdl-2.19.so 7f31a1188000-7f31a1387000 ---p 00003000 fd:00 535286 /lib/x86_64-linux-gnu/libdl-2.19.so 7f31a1387000-7f31a1388000 r--p 00002000 fd:00 535286 /lib/x86_64-linux-gnu/libdl-2.19.so 7f31a1388000-7f31a1389000 rw-p 00003000 fd:00 535286 /lib/x86_64-linux-gnu/libdl-2.19.so 7f31a1389000-7f31a1528000 r-xp 00000000 fd:00 535301 /lib/x86_64-linux-gnu/libc-2.19.so 7f31a1528000-7f31a1728000 ---p 0019f000 fd:00 535301 /lib/x86_64-linux-gnu/libc-2.19.so 7f31a1728000-7f31a172c000 r--p 0019f000 fd:00 535301 /lib/x86_64-linux-gnu/libc-2.19.so 7f31a172c000-7f31a172e000 rw-p 001a3000 fd:00 535301 /lib/x86_64-linux-gnu/libc-2.19.so 7f31a172e000-7f31a1732000 rw-p 00000000 00:00 0 7f31a1732000-7f31a179e000 r-xp 00000000 fd:00 524394 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f31a179e000-7f31a199e000 ---p 0006c000 fd:00 524394 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f31a199e000-7f31a199f000 r--p 0006c000 fd:00 524394 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f31a199f000-7f31a19a0000 rw-p 0006d000 fd:00 524394 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f31a19a0000-7f31a1b6b000 r-xp 00000000 fd:00 131288 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f31a1b6b000-7f31a1d6b000 ---p 001cb000 fd:00 131288 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f31a1d6b000-7f31a1d88000 r--p 001cb000 fd:00 131288 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f31a1d88000-7f31a1d98000 rw-p 001e8000 fd:00 131288 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f31a1d98000-7f31a1d9b000 rw-p 00000000 00:00 0 7f31a1d9b000-7f31a1df1000 r-xp 00000000 fd:00 133362 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 7f31a1df1000-7f31a1ff1000 ---p 00056000 fd:00 133362 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 7f31a1ff1000-7f31a1ff4000 r--p 00056000 fd:00 133362 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 7f31a1ff4000-7f31a1ffb000 rw-p 00059000 fd:00 133362 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 7f31a1ffb000-7f31a201b000 r-xp 00000000 fd:00 535260 /lib/x86_64-linux-gnu/ld-2.19.so 7f31a220b000-7f31a2210000 rw-p 00000000 00:00 0 7f31a2217000-7f31a221b000 rw-p 00000000 00:00 0 7f31a221b000-7f31a221c000 r--p 00020000 fd:00 535260 /lib/x86_64-linux-gnu/ld-2.19.so 7f31a221c000-7f31a221d000 rw-p 00021000 fd:00 535260 /lib/x86_64-linux-gnu/ld-2.19.so 7f31a221d000-7f31a221e000 rw-p 00000000 00:00 0 7fff1cf05000-7fff1cf2d000 rw-p 00000000 00:00 0 [stack] 7fff1cffc000-7fff1cffe000 r-xp 00000000 00:00 0 [vdso] 7fff1cffe000-7fff1d000000 r--p 00000000 00:00 0 [vvar] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] After ca. one hour it went yellow again with the following error output: "symlink nongreen.xml->index.wml failed: Transport endpoint is not connected". Shortly thereafter it went green again, but the runtime is about 1.5 times as high as before. xymon is installed from Debian's xymon packages. Feel free to tell me what else could be helpful to track down this bufferflow. I've found no (recent) core dump. Kind regards, Axel Beckert -- Axel Beckert <beckert at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/

2 8

HTTP test -- 404 results in yellow status?
by hobbit＠elyograg.org 05 Oct '15

05 Oct '15

Below is the text of the status page for the HTTP test on one of my hosts, copied out of a browser window. Note that the specific test line shows "red" (the X icon) ... but this test as a whole is showing a yellow status, and therefore we did not receive an alarm notification. This is monitoring a production website and we were notified of the problem by the customer, not our own monitoring. This makes us look unprofessional. Why would a 404 response code not result in a red status, especially when the inner test is marked red in the text? The Xymon server is version 4.3.21, built as an RPM from unmodified source. I do have "delayred=http:10" on the hosts.cfg line. Could this be a case where the customer notified us before the delayred period expired? Thanks, Shawn =================================== Mon Oct 5 10:29:12 2015: Not Found red http://spark.REDACTED.com:8080/ - Not Found HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Length: 0 Date: Mon, 05 Oct 2015 16:28:24 GMT Connection: close Seconds: 0.01

3 2

rrdtool binaries/libraries used by Xymon?
by mvanderw＠nd.edu 03 Oct '15

03 Oct '15

Hello, How does Xymon determine what rrdtool (set of) binaries/libraries to use for graphing? Does it just use the PATH variable set in /etc/xymon/xymonserver.cfg (generally speaking, $XYMONHOME/etc/xymonserver.cfg)? (i.e. it finds the rrdtool binaries to use based on the precedence given in the PATH variable.) I ask because I am looking at using a newer version of rrdtool (then the rrdtool RPM in the regular RHEL repositories) that I built from source in an alternate location (/opt) and want to tell Xymon to use these new rrdtool binaries/libraries for it's graphing (mostly to see if it works and see what changes). I'm trying to use the latest stable release version 1.5.4, whereas I have been using version 1.4.8. Or do I have a complete misunderstanding of how Xymon utilizes rrdtool? I assumed that it uses the external rrdtool binaries/libraries (as the rrdtool package was a dependency when I installed the xymon server RPM), but maybe it gets built in somehow? FYI, I'm using 4.3.21-4.el7.terabithia RPMs on RHEL 7. Thanks! -- Matt Vander Werf HPC System Administrator University of Notre Dame Center for Research Computing - Union Station 506 W. South Street South Bend, IN 46601 Phone: (574) 631-0692

2 2

Trouble building CentOS RPM of 4.3.21
by Paul.Root＠CenturyLink.com 02 Oct '15

02 Oct '15

Hi, I've been working on building a new rpm for my configuration of xymon 4.3.21. I went through line by line, to get the install the way I wanted it, and everything seemed good. The xymon-client rpm works just fine. But I can't install the server rpm, It wants librrd.so.4. $ rpm -ivh xymon-4.3.21-1.x86_64.rpm-wants-librrd.so.4 error: Failed dependencies: librrd.so.4()(64bit) is needed by xymon-4.3.21-1.x86_64 xymon-client conflicts with xymon-4.3.21-1.x86_64 I am trying to install on the machine I built it on, which has rrdtools 2 installed. lib64rrdtool2-1.2.18-1.rhel5 rrdtool-1.2.18-1.rhel5 librrdtool2-1.2.18-1.rhel5 perl-rrdtool-1.2.18-1.rhel5 I'm building again right now after taking out the BuildRequires: lib64rrdtool2 line. Any ideas? Name: xymon Version: 4.3.21 Release: 1 Group: Networking/Daemons URL: http://xymon.sourceforge.net/ License: GPL Source: xymon-4.3.21.tar.gz Source1: xymon-init.d Source2: xymon.logrotate Source3: xymon-client.init Source4: xymon-client.default Summary: Xymon network monitor BuildRoot: /tmp/xymon-root BuildRequires: openssl-devel BuildRequires: pcre-devel #BuildRequires: rrdtool-devel #BuildRequires: lib64rrdtool2 BuildRequires: openldap-devel Conflicts: xymon-client %description Xymon (previously known as Hobbit) is a system for monitoring your network servers and applications. This package contains the server side of the Xymon package. %package client Summary: Xymon client reporting data to the Xymon server Group: Applications/System Conflicts: xymon %description client This package contains a client for the Xymon (previously known as Hobbit) monitor. Clients report data about the local system to the monitor, allowing it to check on the status of the system load, filesystem utilisation, processes that must be running etc. %prep rm -rf $RPM_BUILD_ROOT %setup USEXYMONPING=n \ USEFPING=n \ ENABLESSL=y \ ENABLELDAP=y \ ENABLELDAPSSL=y \ XYMONUSER=xymon \ XYMONTOPDIR=/usr/lib64/xymon \ XYMONVAR=/var/lib/xymon \ XYMONHOSTURL=/xymon \ CGIDIR=/usr/lib64/xymon/cgi-bin \ XYMONCGIURL=/xymon-cgi \ SECURECGIDIR=/usr/lib64/xymon/cgi-secure \ SECUREXYMONCGIURL=/xymon-seccgi \ HTTPDGID=apache \ XYMONLOGDIR=/var/log/xymon \ XYMONHOSTNAME=localhost \ XYMONHOSTIP=127.0.0.1 \ MANROOT=/usr/local/man \ INSTALLBINDIR=/usr/lib64/xymon/server/bin \ INSTALLETCDIR=/usr/lib64/xymon/server/etc \ INSTALLWEBDIR=/usr/lib64/xymon/data \ INSTALLEXTDIR=/usr/lib64/xymon/server/ext \ INSTALLTMPDIR=/var/lib/xymon/tmp \ INSTALLWWWDIR=/var/lib/xymon/www \ ./configure %build PKGBUILD=1 make %install INSTALLROOT=$RPM_BUILD_ROOT PKGBUILD=1 make install mkdir -p $RPM_BUILD_ROOT/etc/init.d cp %{SOURCE1} $RPM_BUILD_ROOT/etc/init.d/xymon cp %{SOURCE3} $RPM_BUILD_ROOT/etc/init.d/xymon-client mkdir -p $RPM_BUILD_ROOT/etc/logrotate.d cp %{SOURCE2} $RPM_BUILD_ROOT/etc/logrotate.d/xymon mkdir -p $RPM_BUILD_ROOT/etc/sysconfig cp %{SOURCE4} $RPM_BUILD_ROOT/etc/sysconfig/xymon-client mkdir -p $RPM_BUILD_ROOT/usr/bin cd $RPM_BUILD_ROOT/usr/bin && ln -sf ../lib64/xymon/server/bin/{xymon,xymoncmd} . mkdir -p $RPM_BUILD_ROOT/etc/httpd/conf.d rmdir $RPM_BUILD_ROOT/usr/lib64/xymon/client/tmp cd $RPM_BUILD_ROOT/usr/lib64/xymon/client && ln -sf /tmp tmp rmdir $RPM_BUILD_ROOT/usr/lib64/xymon/client/logs cd $RPM_BUILD_ROOT/usr/lib64/xymon/client && ln -sf ../../../../var/log/xymon logs #mkdir -p $RPM_BUILD_ROOT/usr/lib64/xymon/server/www mkdir -p $RPM_BUILD_ROOT/usr/lib64/xymon/server/www/rep mkdir -p $RPM_BUILD_ROOT/usr/lib64/xymon/server/www/snap mkdir -p $RPM_BUILD_ROOT/usr/lib64/xymon/server/www/menu mkdir -p $RPM_BUILD_ROOT/etc/xymon mv $RPM_BUILD_ROOT/usr/lib64/xymon/server/etc/* $RPM_BUILD_ROOT/etc/xymon mv $RPM_BUILD_ROOT/etc/xymon/xymon-apache.conf $RPM_BUILD_ROOT/etc/httpd/conf.d/ mkdir -p $RPM_BUILD_ROOT/etc/xymon/web mv $RPM_BUILD_ROOT/usr/lib64/xymon/client/etc/xymonclient.cfg /tmp/xymonclient.cfg.$$ cat /tmp/xymonclient.cfg.$$ | sed -e 's!^XYMSRV=.*!include /var/run/xymonclient-runtime.cfg!' | grep -v "^XYMSERVERS=" >$RPM_BUILD_ROOT/usr/lib64/xymon/client/etc/xymonclient.cfg rm /tmp/xymonclient.cfg.$$ mv $RPM_BUILD_ROOT/usr/lib64/xymon/client/etc/* $RPM_BUILD_ROOT/etc/xymon [ -d $RPM_BUILD_ROOT/usr/lib64/xymon/server/etc ] && rmdir $RPM_BUILD_ROOT/usr/lib64/xymon/server/etc cd $RPM_BUILD_ROOT/usr/lib64/xymon/server && ln -sf /etc/xymon etc [ -d $RPM_BUILD_ROOT/usr/lib64/xymon/client/etc ] && rmdir $RPM_BUILD_ROOT/usr/lib64/xymon/client/etc cd $RPM_BUILD_ROOT/usr/lib64/xymon/client && ln -sf /etc/xymon etc mkdir -p $RPM_BUILD_ROOT/var/lib/xymon/tmp %clean rm -rf $RPM_BUILD_ROOT %pre id xymon 1>/dev/null 2>&1 if [ $? -ne 0 ] then groupadd xymon || true useradd -g xymon -c "Xymon user" -d /usr/lib64/xymon xymon fi if [ -e /var/log/xymon/xymonlaunch.pid -a -x /etc/init.d/xymon ] then /etc/init.d/xymon stop || true fi %pre client id xymon 1>/dev/null 2>&1 if [ $? -ne 0 ] then groupadd xymon || true useradd -g xymon -c "Xymon user" -d /usr/lib64/xymon xymon fi if [ -e /var/log/xymon/clientlaunch.pid -a -x /etc/init.d/xymon-client ] then /etc/init.d/xymon-client stop || true fi %post chkconfig --add xymon %post client chkconfig --add xymon-client %preun if [ -e /var/log/xymon/xymonlaunch.pid -a -x /etc/init.d/xymon ] then /etc/init.d/xymon stop || true fi chkconfig --del xymon %preun client if [ -e /var/log/xymon/clientlaunch.pid -a -x /etc/init.d/xymon-client ] then /etc/init.d/xymon-client stop || true fi chkconfig --del xymon-client %files %attr(-, root, root) %doc README README.CLIENT Changes* COPYING CREDITS RELEASENOTES %attr(644, root, root) %doc /usr/local/man/man*/* %attr(644, root, root) %config /etc/xymon/* %attr(644, root, root) %config /etc/httpd/conf.d/xymon-apache.conf %attr(755, root, root) %dir /etc/xymon %attr(755, root, root) %dir /etc/xymon/tasks.d %attr(755, root, root) %dir /usr/lib64/xymon/server/download %attr(755, root, root) %dir /etc/xymon/web %attr(755, xymon, xymon) %dir /var/log/xymon %attr(755, root, root) /etc/init.d/xymon %attr(644, root, root) /etc/logrotate.d/xymon %attr(-, root, root) /usr/lib64/xymon %attr(-, root, root) /usr/bin/* %attr(-, xymon, xymon) /var/lib/xymon %attr(775, xymon, apache) %dir /var/lib/xymon/www/rep %attr(775, xymon, apache) %dir /var/lib/xymon/www/snap %attr(644, root, root) %config /var/lib/xymon/www/menu/xymonmenu-grey.css %attr(644, root, root) %config /var/lib/xymon/www/menu/xymonmenu-blue.css %attr(755, xymon, xymon) %dir /usr/lib64/xymon/client/ext %attr(664, xymon, apache) %config /usr/lib64/xymon/server/etc/critical.cfg %attr(4750, root, xymon) /usr/lib64/xymon/server/bin/xymonping %attr(750, root, xymon) /usr/lib64/xymon/client/bin/logfetch %attr(750, root, xymon) /usr/lib64/xymon/client/bin/clientupdate %files client %attr(-, root, root) %doc README README.CLIENT Changes* COPYING CREDITS RELEASENOTES %attr(-, root, root) /usr/lib64/xymon/client %attr(755, root, root) /etc/init.d/xymon-client %attr(644, root, root) %config /etc/sysconfig/xymon-client %attr(755, xymon, xymon) %dir /var/log/xymon Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 390 Commerce Dr Woodbury, MN 55125 Direct: (651)312-5207 Paul.Root at centurylink.com This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

1 1

DOWNTIME syntax question
by glauber.ribeiro＠experian.com 02 Oct '15

02 Oct '15

Hello, I need to express 2 different downtimes (for 2 different statuses) on one of our servers. For example (made up but similar to what I need): DOWNTIME=col1:0:0200:0300 DOWNTIME=col2:1:0500:0700 Is this supported? Should I just have 2 DOWNTIME entries in that server’s entry in hosts.cfg, or should I somehow combine them? Thanks, glauber

1 0

Display IP address on webpage
by jlaidman＠rebel-it.com.au 30 Sep '15

30 Sep '15

> > Is there a way to display the IP address instead of the hostname in the > overview webpages. I suppose I can use the NAME tag but it would mean I > have to add NAME tags to every host in host.cfg > Firsty, I'm curious why you would want to show the IP address and not the hostname. If the IP address is more useful, why aren't the devices named "device-192-168-0-100"? Secondly, do you know that you can click on an "info" link and get the IP addres? Thirdly, I'm not aware of a simple way to do what you're asking, certainly nothing built in to Xymon. Here are a few non-trivial options: 1. Modify the source code ;-) Actually, there are several features that I'd love to see configurable in xymongen, such as: a) hover or click to show a pop-up with some basic information about the server, perhaps some or all of the "info" page, or the contents of the "notes" page; b) configurable click-to-connect to launch telnet:// or ssh:// URLs; c) click to popup an offline/online option for the host; d) similar for shift-clicking on a status dot. Most, if not all of these, would have to be implemented in JavaScript, at least in part. But an option to expand some variables in the NAME: and DESCR: tags to include $IP would be coded directly in xymongen C code. 2. You could automate the generation of the NAME tags in hosts.cfg. Perhaps you could have a "hosts.src" file, and then you periodically create "hosts.cfg" such that it contains everything in "hosts.src" with an extra "NAME:192.168.0.100" type tag. 3. You could do a similar thing, but build a special include file containing only the IP address, hostname and alternative hostname, then use "dispinclude" to include this file BEFORE the real host description. Like this: *hosts.cfg:* dispinclude named-by-ip.cfg 192.168.0.100 host1.example.com # noconn ssh 192.168.1.53 host2.example.com # dns *named-by-ip.cfg:* 192.168.0.100 host1.example.com # NAME:192.168.0.100 192.168.1.53 host2.example.com # NAME:192.168.1.53 You would simply generate the file "named-by-ip.cfg" automatically whenever hosts.cfg is updated, or periodically. 4. You could probably do this sort of thing with some javascript magic. I'm guessing it would be possible to include a little javascript within the page footer, that scans through the <span title=> tags, performs a web lookup to the "info" column to get the IP address, and replaces the hostname text. I've done this kind of thing to allow hostnames to be clickable, enhancing the hostname text to be a hotlink to an "ssh://" or "telnet://" style URL. Described here: http://lists.xymon.com/archive/2012-March/034227.html

4 4

Ext to alert once a day
by rltexas1＠gmail.com 30 Sep '15

30 Sep '15

I have an ext script that runs once every 24 hours. How can I configure the alerts to only send an email once a day if the status is x color. Thanks

3 3

BUG: ntpdate command used in Xymon takes 2+ seconds each in RHEL 7 (with ntp 4.2.6+)
by mvanderw＠nd.edu 30 Sep '15

30 Sep '15

Hello J.C., etc. (Brief Summary) I noticed a issue/bug in the way Xymon uses the ntpdate command for it's built-in ntp checks. Each ntp test (using the ntpdate options hard-coded into Xymon) takes >= 2 seconds to run in any OS that uses upstream ntp version 4.2.6 or later, including RHEL 7. This is due to a 2 second delay that was put in place in upstream ntp starting with version 4.2.6. While RHEL 6 uses upstream ntp 4.2.6 in it's latest iteration, the behavior I'm referring to was reverted by Red Hat when RHEL 6 moved from using version 4.2.4 to 4.2.6 in a minor release. This was because this kind of major change in behavior was not desired in only a minor RHEL release. However, in RHEL 7 it was acceptable to keep this behavior change in place since it was a major OS release. (Detailed (continued) Summary) Initially, I thought it was a Red Hat issue, so a support ticket was opened up with Red Hat to figure out what the issue was. The support person was able to replicate the issue I was seeing and created a public Bugzilla bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1260140. The ntp package maintainer for Red Hat replied saying this was intended behavior and while reverted in RHEL 6, it would not be reverted in RHEL 7. I asked in the support ticket why it was not going to be fixed in RHEL 7 and got this response in the support ticket: "The original ntp version shipped in RHEL6 was 4.2.4, which had ntpdate that was fast, but violated the default 2s minimum spacing between requests. An NTP server with enabled rate limiting would not respond more than once to such client. In ntp 4.2.6 that bug was fixed by adding spacing between the requests, which slows down the ntpdate operation. This change in behavior was not acceptable for a minor RHEL6 release, so the bug was restored in a patch. In RHEL7 as a new major release I think such change is acceptable and ntpdate now works as upstream intended." Please see public Bugzilla bug for additional links for reference of this change in behavior. (Request) *It would be greatly appreciated if this could be fixed in upstream Xymon ASAP! However, since my Xymon server was installed using Terabithia RPMs, what is most important to me is to get an updated Terabithia RPM created that I can use to update my Xymon server. I understand that a source code patch has already been created for Debian Xymon here: https://anonscm.debian.org/cgit/collab-maint/xymon.git/tree/debian/patches/… (referenced in earlier mailing list post: http://lists.xymon.com/pipermail/xymon/2015-September/042224.html) This would work perfectly!! However, since I am using Terabithia RPMs, it is not very easy to simply apply this above patch and recompile the base source code and use that, since I am I not using just the base source code. Maybe a hotfix release of Xymon could be created and released sometime very soon with this fix? Currently, I am unable to do all the ntp tests I would like to do because it causes xymonnet to go over the 5 minute interval time!.... In the meantime, would it be possible for someone (maybe J.C.) to create a binary patch or something that I could apply to the current xymonnet binary with the fix in the above patch? Just a thought...and would be extremely appreciated!! Thank you very much for your time and work you do to make Xymon a great monitoring tool! I look forward to some fixes being applied to resolve this issue with the ntp tests! TL;DR: ntp checks take WAY to long in Xymon using hard-coded ntpdate options, due to change in ntpdate behavior starting in upstream ntp version 4.2.6. This particularly affects Xymon servers running on RHEL 7 (and new releases in the future). Hotfix needed in Xymon to fix this issue (see source code patch above) ASAP! If possible, a binary patch to xymonnet binary would be much preferred in the meantime! I am using Terabithia RPMs for my Xymon server, so using above source code patch is not possible or desirable! FYI: I am running Xymon 4.3.21-4.el7.terabithia for my Xymon server. Thanks!! -- Matt Vander Werf

2 3