1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Known issues in Xymon</title>
</head>
<body>
<h1>Known issues in Xymon</h1>
<p>This describes some known problems you may encounter when
using Xymon to monitor servers.</p>
<ul>
<li><a href="#bugreport">How to report bugs</a></li>
<li><a href="#jsval">JavaScript errors when using enable/disable function</a></li>
<li><a href="#dnserror">DNS error reported for network tests</a></li>
<li><a href="#netfail">Network tests fail sporadically</a></li>
<li><a href="#solarisrandom">"Failed to find enough entropy" on Solaris</a></li>
<li><a href="#freebsdkernelsem">Xymon fails on FreeBSD with "Could not get sem: No space left on device"</a></li>
<li><a href="#solarislinker">Xymon on Solaris compiles but aborts with some "ld.so" error</a></li>
</ul>
<h3><a name="bugreport">How to report bugs</a></h3>
<p>If you think you have found a bug in Xymon, please report it
to the Xymon mailing list at <a href="mailto:xymon@xymon.com">xymon@xymon.com</a>.
You can do a lot to help getting bugs fixed by providing detailed information
about the bug:</p>
<ul>
<li>Always include the version number of Xymon you're using</li>
<li>If one of the Xymon tools crashes and leaves a core-file (usually
in the ~xymon/server/tmp/ directory), please use the <b>gdb</b> tool to
pinpoint where the crash occurred:<br>
<ul>
<li>Login as the Xymon user</li>
<li><tt>
$ <b>cd ~/server</b><br>
$ <b>gdb bin/PROGRAMFILE tmp/COREFILE</b><br>
</tt>then at the <tt>gdb></tt> prompt, execute the command<br>
<tt>
gdb> <b>bt</b>
</tt></li>
</ul>
</ul>
<h3><a name="jsval">Internet Explorer complains about Javascript errors in Enable/Disable</a></h3>
<p>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.</p>
<h3><a name="dnserror">DNS error reported for network tests</a></h3>
<p>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.</p>
<h3><a name="netfail">Network tests fail sporadically, or report long response times</a></h3>
<p>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 <tt>~/server/etc/tasks.cfg</tt>
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.</p>
<h3><a name="solarisrandom">Network tests fail on Solaris with "Failed to find enough entropy"</a></h3>
<p>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 <b>patch 112438</b> solves this
by adding a /dev/random device that provides random data to applications.<br>
Thanks to Scott Kelley for the pointer to the Solaris patch.</p>
<p>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 <a href="http://www.cosy.sbg.ac.at/~andi/SUNrand/">http://www.cosy.sbg.ac.at/~andi/SUNrand/</a>.
I have been using ANDIrand since that did not require a reboot and easily
available.
</p>
<h3><a name="freebsdkernelsem">Xymon fails on FreeBSD with "Could not get sem: No space left on device"</a></h3>
<p>Xymon uses some kernel resources - semaphores and shared memory.
If you get the following error message in xymonlaunch.log when trying
to start Xymon:</p>
<pre><tt>
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
</tt></pre>
<p>then you need to increase the number of semaphore sets and
individual semaphores available to applications.</p>
<p>The current settings for your kernel can be found with
"<tt>sysctl kern.ipc.semmni</tt>" (semaphore sets)
and "<tt>sysctl kern.ipc.semmns</tt>" (total number
of semaphores). Xymon uses 6 semaphore sets, with a total of 18 semaphores.</p>
<p>To increase this, put these two lines in /boot/loader.conf on your system:</p>
<pre><tt>
kern.ipc.semmni="40"
kern.ipc.semmns="100"
</tt></pre>
<p>Adjust the values to something reasonable for your system - considering the
current settings (from the <tt>sysctl</tt> output), and Xymon's needs
(6 sets with 18 semaphores).</p>
<p>More information about tuning the FreeBSD kernel parameters is available in
<a href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-sysctl.html">
the FreeBSD Handbook</a></p>
<h3><a name="solarislinker">Xymon on Solaris compiles but aborts with some "ld.so" error</a></h3>
<p><a href="http://www.xymon.com/archive/2005/09/msg00160.html">This info</a> was contributed by sladewig,
with a few modifications:</p>
<center>
<table width="80%" border=1><tr><td>
<p>The system loader/linker can't find your lib.</p>
<p>Assuming you have the .so lib in /usr/local/lib,
You can add -R to the Makefile</p>
<p><tt>
PCRELIBS = -L/usr/local/lib -R/usr/local/lib -lpcre
</tt></p>
<p>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.</p>
<p>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!</p>
<p>Command line:</p>
<p><tt>
crle -c /var/ld/ld.config -l /usr/lib:/usr/lib/secure:/usr/local/lib
</tt></p>
<p>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.</p>
</td></tr></table>
</center>
<p>Note: This information only applies if you are using the Solaris linker.
The GNU linker uses the "-rpath" option which is defined differently: Add</p>
<p><tt>
RPATH = -Wl,--rpath=
</tt></p>
<p>at the bottom of the top-level Makefile.</p>
</body>
</html>
|
