This describes some known problems you may encounter when using Xymon to monitor servers.
If you think you have found a bug in Xymon, please report it to the Xymon mailing list at email@example.com. You can do a lot to help getting bugs fixed by providing detailed information about the bug:
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.
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.
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 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:
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
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!
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.