On 2/22/2017 2:52 PM, Lynn Osburn wrote:

Thanks to several of you who made Linux-specific recommendations. While this is an HP-UX install, I did check to ensure that rrdtools had the necessary libraries to compile and link, for example. The output of the configure command includes the following lines Checking for RRDtool ... Not RRDtool 1.0.x, checking for 1.2.x Compiling with RRDtool works OK Linking with RRDtool works OK

I think the key symptom is that nothing is being written into the /opt/xymon/data/rrd directory. Not even the creation of the subdirectory for each target in hosts.cfg.

I added the "--debug" option to both the rrd-data and rrd-status channels in tasks.cfg, in hopes of finding something more useful in the /var/log/rrd-status.log but all I'm getting there is still endless repeats of "Peer not up, flushing message queue"

Client data is being received. I can see it by clicking the xymon server, then in the svcstatus page I can click on "Client data" and see the raw inputs. This tells me there is no trouble binding the port, and that the client is communicating with the server.

What part of the code detects a new host in the hosts.cfg file and sets up the necessary directories in /opt/xymon/data/hist, /opt/xymon/data/histlogs, /opt/xymon/data/hostdata and /opt/xymon/data/rrd ??

When you're adding --debug, are you giving it as an option to xymond_channel or to xymond_rrd? It needs to be for the latter to enhance the output for that. Something like "CMD xymond_channel --channel=status xymond_rrd --debug"

"Peer not up, flushing message queue" is an output symptom of xymond_channel dealing with xymond_rrd not being up (either can't launch successfully, exits immediately, or crashes, etc).

Generally speaking, each channel worker is responsible for creating per-host directories and files under each of the directories it's responsible for. xymond_history handles /hist/ and /histlogs/, xymond_hostdata handles /hostdata/, xymond_rrd handles /rrd/, and xymond_filestore tasks (if enabled) handle most of the rest. Creation for most (all?) occurs on receipt of the associated messages and not just by virtue of existence in hosts.cfg, though removals from hosts.cfg (drop messages) will cause cleanup.

HTH, -jc