Glad to see you have it working now.

Yeah, two Xymon servers means the second one's client-local.cfg is used because it's the one that the client contacts last of all. I've been bitten by that several times in the past.

J

On Sat, 25 June 2022, 01:42 POLYAK, TIM P, <tp6891 at att.com> wrote:

Hi,

What I meant by non standard log file was just not the default /var/adm/messages.

Looking at the contents of a different file example /var/adm/6800.log.

Server client-local.cfg file

[Fully-Qualified-Hostname]

log:/var/adm/messages:10240

file:/var/adm/6800.log

log:/var/adm/6800.log:10240

Update I did find my trouble. I was updating 1 of 2 xymon servers correctly the test/backup server but I found the primary xymon server was over writing my changes in the tmp/logfetch.Fully-Qualified-Hostname.cfg after the test/backup server made the changes. I was in a loop where 1 xymon server made the change and the other xymon server changed it back.

Thank you for pointing out the xymon server updates the client tmp/logfetch.Fully-Qualified-Hostname.cfg when you make changes to the servers etc/client-local.cfg

Thanks

Tim

*From:* Jeremy Laidman <jeremy at laidman.org> *Sent:* Wednesday, June 22, 2022 6:53 PM *To:* POLYAK, TIM P <tp6891 at att.com> *Cc:* xymon at xymon.com *Subject:* Re: [Xymon] trying to monitor non-standard logfile with server client-local.cfg and failing

Hi Tim

On Thu, 23 Jun 2022 at 02:24, POLYAK, TIM P <tp6891 at att.com> wrote:

I am trying to monitor non-standard logfile with server client-local.cfg and failing.

Can you explain how it's non-standard? Are you trying to monitor the contents or the attributes of the file? Would a "log:/var/adm/6800.log" entry be more suitable for a logfile?

Here is what I tried so far in the client-local.cfg file

[host=hostname]

file:/var/adm/6800.log and

[hostname]

file:/var/adm/6800.log

The correct format is the latter.

Firstly, note that it can take something like 10 minutes for log/file monitoring to start reporting due to delays in propagating the config to the clients, and then for the clients to report back again based on the config.

What I would do is look in the $XYMONTMP directory on the client (defined in xymonclient.cfg, often /tmp, /var/tmp or /dev/shm) for the temporary files created by the client. They will be called logfetch.<hostname>.cfg and logfetch.<hostname>.status.

The cfg file is essentially just the [hostname] section from the client-local.cfg, retrieved when the client last reported to the server.

The status file has a line for every "file:" entry in the client-local.cfg file, and is used to track the logfile position on each run. If you don't have any "file:" entries in your client-local.cfg file for a server, it might not have a status file.

So, first see if the cfg file is present. If not, your update to client-local.cfg might not have been detected by the xymond process on the Xymon server. Usually it picks this up by itself, but if not, you could restart xymond and see if that helps (again, wait 10 minutes to see progress). If the cfg file is present, see if its contents make sense (that is, match what's in the client-local.cfg file on the server).

J