On 12/15/2010 10:10 AM, François Claire wrote:
I tried to compile the xymon client on Mac OS X 10.6 and ran into the same problem that was reported about a year ago[1].
You may already know it but Xymon is available for Mac OS X through the macports project: http://www.macports.org/ports.php?by=name&substr=xymon https://trac.macports.org/wiki/howto/SetupXymonServer
It simplifies the compilation/install process.
I have seen your mail about the macports but I didn't want to install macports just to monitor some Mac clients.
Unfortunately, the default behaviour for the Mac HFS+ file system is to ignore case so the two files get mixed up. The solution to this is fairly simple. Just drop the -I. from the CFLAGS options. Having -I. should not be necessary anyway because the preprocessor differentiates between #include <file.h> and #include "file.h" precisely to separate system includes from project includes. Indeed, I hit this problem and used the following patch: http://trac.macports.org/browser/trunk/dports/net/xymon/files/patch-build-Ma...
I didn't specifically look into your patches at the time and naively assumed that anything that would fix a problem was integrated into the most current version. Or rather, anything missing from the current trunk needed a patch anyway.
Anyway, your patch and mine agree on this point and I would consider it safe to apply. It will be up to Henrik though to make that decision.
Once this problem is solved, there are two more problems that will arise. The first one would be the same on all platforms whenever xymon is built without SSL support (not needed on the client). In lib/sendmsg.c TALK_SSLWRITE_RECEIVE will be referenced even though the enum only goes up to TALK_RECEIVE when HAVE_OPENSSL is not defined.
The second problem ist with the zlib where the dynamic library for Mac OS X is in /usr/lib/libz.dylib which does not get search.
I didn't encounter those 2 problems. Strange.
They are not entirely Mac related but will pop up whenever either the SSL or zlib are not found. With macports you may have enough infrastructure that it detects both and the compile goes through like on other systems with SSL and zlib.
If SSL or zlib are missing (or not found) then the code does not compile. As I do not consider SSL to be important for the client, I decided to fix the code. On a server I would recomment using your macports package anyway.
For the zlib support I wanted to have that on the client too, so I fixed the detection for the case of a standard Mac OS X installation with the current Xcode, but without macports. The case without zlib still looks broken to me but I cannot rule out that it is a Mac specific thing with the detection script (it finds the include files but not the library and complains at the link step).
The attached patch fixes all three problems and the Mac OS X client builds successfully.
I guess Henrik will have a look at them.
By the way, this patch should be useful for you: http://trac.macports.org/browser/trunk/dports/net/xymon/files/patch-client-x...
It fixes the problem of CPU usage reported by Mac OS X xymon clients.
Thank you. That will certainly help.
Hope this helps.
Sure it does. While you're here, could you please help me with a problem I couldn't solve so far: on a Mac OS X Xymon server I have the showgraph.cgi eating up all the CPU when I access xymon webpages containing graphs. -> http://sourceforge.net/mailarchive/message.php?msg_id=26609049
Are you running a xymon server on Mac OS X ? If yes, do you have the same problem with graph generation ?
We are running our server on Debian/Linux with the Debian package. I haven't looked at the xymon-server on the Mac at all, so I'm sorry I cannot provide useful input to this problem at this time. It could have something to do with rrdtool which I don't have installed on the client either.
Regards, -- Elamr
-- Dr. Elmar S. Heeb <heeb at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT D 19 voice: +41 44 633 25 91 Department of Physics, ETH Zurich mobile: +41 79 628 75 24 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Please consider the environment before printing this e-mail