Known issues in Xymon

This describes some known problems you may encounter when using Xymon to monitor servers.

How to report bugs

If you think you have found a bug in Xymon, please report it to the Xymon mailing list at xymon@xymon.com. You can do a lot to help getting bugs fixed by providing detailed information about the bug:

Internet Explorer complains about Javascript errors in Enable/Disable

This happens for some, but works for most people. One workaround is to disable the Javascript validation code in the enable/disable function: Edit ~xymon/cgi-bin/enadis.sh script and add the option "--no-jsvalidation" to the hobbisvc.cgi command - this disables Javascript validation on the "info" page - and edit the file ~xymon/server/web/maint_form so you remove the text 'onClick="validateDisable(this.form)"' from the input-tag near the end of that file.

DNS error reported for network tests

The xymonnet network tester uses the built-in ARES library for DNS lookups. There have been reports that this library fails on some systems; one confirmed case is on "OSF1 V5.1". So if you suddenly get a lot of failed network tests that report "DNS error", try running xymonnet with the "--no-ares" option to use the standard DNS lookups instead.

Network tests fail sporadically, or report long reponsetimes

The xymonnet network tester runs many tests in parallel; by default it will typically run up to 256 tests concurrently. This may be more than your network test server or network infrastructure can handle; if you see sporadic timeouts of network tests or the graphs show increased responsetimes, you can lower the number of concurrent tests by adding the "--concurrency=N" option to xymonnet in the ~/server/etc/tasks.cfg file. This has been especially important for sites doing many http checks, since these typically have much more traffic going on while testing than simple TCP services such as smtp.

Network tests fail on Solaris with "Failed to find enough entropy"

OpenSSL uses random data to initialise a key that is negotiated when a new SSL-encrypted connection is being setup. Solaris 8 and earlier doesn't have a standard way of getting random data, so OpenSSL cannot get all of the randomness it needs. Solaris patch 112438 solves this by adding a /dev/random device that provides random data to applications.
Thanks to Scott Kelley for the pointer to the Solaris patch.

Asif Iqbal notes: Patch 112438 only works for Solaris 8. For Solaris 6 and 7 you need to either install SUNWski pkg or ANDIrand pkg. See http://www.cosy.sbg.ac.at/~andi/SUNrand/. I have been using ANDIrand since that did not require a reboot and easily available.

Xymon fails on FreeBSD with "Could not get sem: No space left on device"

Xymon uses some kernel resources - semaphores and shared memory. If you get the following error message in xymonlaunch.log when trying to start Xymon:


2005-05-29 20:25:14 Setting up xymond channels
2005-05-29 20:25:14 Could not get sem: No space left on device
2005-05-29 20:25:14 Cannot setup status channel
2005-05-29 20:25:14 Task xymond terminated, status 1

then you need to increase the number of semaphore sets and individual semaphores available to applications.

The current settings for your kernel can be found with "sysctl kern.ipc.semmni" (semaphore sets) and "sysctl kern.ipc.semmns" (total number of semaphores). Xymon uses 6 semaphore sets, with a total of 18 semaphores.

To increase this, put these two lines in /boot/loader.conf on your system:


kern.ipc.semmni="40"
kern.ipc.semmns="100"

Adjust the values to something reasonable for your system - considering the current settings (from the sysctl output), and Xymon's needs (6 sets with 18 semaphores).

More information about tuning the FreeBSD kernel parameters is available in the FreeBSD Handbook

Xymon on Solaris compiles but aborts with some "ld.so" error

This info was contributed by sladewig, with a few modifications:

The system loader/linker can't find your lib.

Assuming you have the .so lib in /usr/local/lib, You can add -R to the Makefile

    PCRELIBS = -L/usr/local/lib -R/usr/local/lib -lpcre

The -R "hard code" the path to the library into the executable so env variable (LD_LIBRARY_PATH, ed.) will not be needed. The -L told it where to find it while compiling.

Or use crle to add /usr/local/lib to system wide runtime linking environment. See man crle. Be VERY CAREFUL with this or you will end up booting from cdrom to repair. Be sure to include the existing library paths!

Command line:

    crle -c /var/ld/ld.config -l /usr/lib:/usr/lib/secure:/usr/local/lib

I usally use the latter as nowadays gcc uses a .so for all its generated programs and then dragging around the LD_LIBRARY_PATH isn't needed.

Note: This information only applies if you are using the Solaris linker. The GNU linker uses the "-rpath" option which is defined differently: Add

    RPATH = -Wl,--rpath=

at the bottom of the top-level Makefile.