January 2024 - Xymon - Xymon mailman web

Possible bug in xymon svcstatus causing segfault (buffer overrun?)
by jeremy＠laidman.org 31 May '24

31 May '24

Hi all I'm not a C programmer by any stretch, so I'm seeking confirmation that my working is sound. At our site we run 4.3.30-1 from Terabithia RPM. For most hosts, the "trends" page displays just fine, but for some hosts, the webserver gives a CGI error, and when I manually run the CGI directly it crashes with a seg fault. This seems to be more likely for hosts with a lot of entries on the trends page, but some with more trends graphs are OK than others with fewer. I believe I've tracked the issue down to the last few lines of code in svcstatus-trends.c, where a URL is constructed for one graph entry, before being added to the list of trends in a buffer. My reading of the code suggests that it first pre-allocates (using malloc()) a 16k buffer for the trends data, then sequentially appends trend strings (which include a URL) into the buffer, until the length of a string would exceed the size of the buffer. In that case, an extra 4k of memory is added to the buffer (using realloc()), and then the string is added to the buffer. The problem with the code, as I see it, is that the string might be more than 4k long, in which case, adding string would cause a buffer overrun. I don't really know what's in each string, so I don't know if it's ever likely to be 4k, but we're seeing the process dumping core immediately after this bit of code, so that's the suspicion. Here's the bit of code, which is attempting to add the string "onelink" to the buffer, after seeing if it's going to exceed the buffer, and extending the buffer if required: if ((buflen + strlen(onelink)) >= allrrdlinks_buflen) { SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+4096); allrrdlinksend = allrrdlinks + buflen; } allrrdlinksend += snprintf(allrrdlinksend, (allrrdlinks_buflen - (allrrdlinksend - allrrdlinks)), "%s", onelink); Elsewhere in other code, the SBUF_REALLOC macro is used to add extra bufferspace by calculating a new buffer size of [existing buffer size plus 4k plus the length of the string being added]. So if the string to be added had 20 bytes, SBUF_REALLOC would be used to add 4k+20 bytes to the buffer size. Notably, the size of the string is included in the calculation. For example this bit of code elsewhere in the same file does a similar buffer extension: if ((strlen(rrdlink) + strlen(partlink) + 1) >= rrdlink_buflen) { SBUF_REALLOC(rrdlink, rrdlink_buflen + strlen(partlink) + 4096); } strncat(rrdlink, partlink, (rrdlink_buflen - strlen(rrdlink))); Note the extra "+ strlen(<stringvar>)" bit in the extra memory being allocated that isn't there in the first block of code above. So my thinking is that the SBUF_REALLOC() needs to take the string's size into account, like so: SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+strlen(onelink)+4096); Is anyone with C skills able to confirm that this does indeed look like a bug, and also that my proposed change is a suitable fix? After applying this change and recompiling, we haven't yet seen a seg fault from this bit of code, so I'm hoping it's all fixed, and without negative side effects. Cheers Jeremy

3 3

Update on 4.4 (Alpha1 release)
by tom＠4schmidts.com 15 May '24

15 May '24

J.C., Thank you again J.C. for reviving the updates for Xymon. I am willing to help update it as well, even though I am now retired and only have a small install of Xymon 4.3.30 at home for my home network. I have contributed to Xymon several times in the past when I had it installed in a large corporate environment before I retired. J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings. I have not fully tested 4.4-alpha1 yet, but wanted to get these first patches released for 4.4-alpha2. Tom Schmidt On Wed, Sep 20, 2023 at 2:38?PM J.C. Cleaver <cleaver at terabithia.org> wrote: > Hello all! Just wanted to update everyone on a few things. > > Going through the 4.x codebase re-familiarizing myself again with the > state of everything, I recalled that I'd actually built a release artifact > before development was paused, including a testing RPM that has actually > been running unbeknownst on a VM for quite a while. Unfortunately, while > validating that compiles from source worked I ran into what looked like > showstopper bugs. These weren't showing up in the package, so I had to > pore through a lot more code* than I expected to try to figure out where > the package was accidentally fixing it. > > (*message-sending code, which changes a lot in 4.4 to support compression, > TLS, HTTP, and size-prefixed messages) > > Fortunately, it ended up being a relatively simple issue (isn't it > always?), with easy-enough validation and workaround (given below). > Although more fixes could be put in (and I'm sure will be needed!), I > believe there's some benefit to having a stable starting point using a > build artifact from 2019. > > As a result, I'm pleased to announce the first alpha for Xymon 4.4! As > this is an alpha release, this is absolutely NOT suitable for production > use and is intended mainly for smoketesting by source users. (And I expect > there will be smoke.) The release tarball is available now at: > > > https://sourceforge.net/projects/xymon/files/Xymon/4.4-alpha/xymon-4.4-alph… > > > Major improvements are too many to list here but are noted in the Changes > and RELEASENOTES files. README documents for compression, TLS, and IPv6 > are in progress. > > Some of the changes and improvements other than TLS support have been in > the Terabithia packages (to some extent) for a while, so there will be > less of a delta for those users to this alpha. > > For the moment, I'd like to focus on source tarball users and others > running xymon from scratch to help fix underlying issues and any smoketest > failures, which I expect may crop up particularly on untested non-Linux > platforms. Once the lower-hanging fruit is fixed and more patches are > upstreamed and cleaned up, I'll release an alpha2 release at which point > packages may be released to help with testing iteration and downstream > distributors. > > Please flag bug reports or patches as related to "alpha1" in the subject > line to help keep things clear. > > > Thank you to everyone in the community for remaining part of it -- and > xymon users! -- during this interregnum. Restarting development has been a > process, but I'm glad to take this important first step to our next > release. > > > Regards, > -jc > > > > *** KNOWN ISSUES -- IMPORTANT *** > > The configure script is likely setting XYMONHOME/XYMONCLIENTHOME and > XYMSRV/XYMSERVERS/XYMONSERVERS incorrectly, which will prevent xymonlaunch > from correctly launching anything. Double check the xymon environment > files (xymonserver/xymonclient.cfg) before starting either the server or > client. > > The tools/xymon-client.default and tools/xymonlaunch files may be placed > into /etc/{sysconfig,default}/{xymon-client,xymonlaunch} to more easily > set $XYMONSERVERS > > Revealed by the above issue is a bug causing a crash in the client (or > anywhere) when given an empty string as the destination argument (instead > of 0, 127.0.0.1 or no variable set). Don't do this --> [ xymon '' "ping" ] > > The client and logfetch binary may be being re-compiled during 'make > install' > > Compilation may fail if c-ares and at least one compression library is not > present (lzo/lz4/zlib are all options). xxHash libraries are also highly > recommended as the plan is for xxhash to replace md5 for checksumming > functionality. libtirpc may be necessary on some platforms, and it's > possible the build code is still expecting traditional (Sun) RPC > > > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

5 6

XymonPSClient CPU graphs missing over HTTPS
by kspringer＠innovateteam.com 31 Jan '24

31 Jan '24

I'm using the XymonPSClient 2.42 on a Windows server, and all works fine except when I choose to send the data from the client to the server over https the CPU graph doesn't display on the server side. If I change the XymonPSClient to send over http the CPU graph displays correctly.? I've tried this on different hosts and results are always the same when using https.? Server is v4.3.30, but it was happening on an older version too.? Can anyone give me a clue how to resolve this?? There's no errors happening that I can see anywhere. I looked in the rrd folder and there is no 'cpu' or 'la' rrd file being created for the hosts that use the XymonPSClient over https. Thanks, Kris Springer

3 9

Xymon no longer sending alerts
by colin.coe＠gmail.com 31 Jan '24

31 Jan '24

The "Select" messages are still there. The faulty alerts.cfg config was: HOST=%(...|GS\d\d\d\d) IGNORE but should have been: HOST=%(...GS\d\d\d\d) IGNORE so basically everything was being ignored On Wed, 31 Jan 2024 at 10:39, Jeremy Laidman <jeremy at laidman.org> wrote: > Great news Colin. > > Have the "Select(2)" messages gone away? > > Can you share the nature of the error in alerts.cfg, so I know what to > look for when I do the same in future? > > J > > On Wed, 31 Jan 2024 at 13:22, Colin Coe <colin.coe at gmail.com> wrote: > >> Hi all >> >> This is resolved. It was a stupid error in alerts.cfg... >> >> Thanks for the suggestions >> >> On Wed, 31 Jan 2024 at 09:21, Colin Coe <colin.coe at gmail.com> wrote: >> >>> Hi Jeremy >>> >>> Running the following gives me the expected result so the server is >>> responding, at least sometimes. >>> xymon 127.0.0.1 "config hosts.cfg" >>> >>> Is this a worry: "Discarding timed-out partial msg from 127.0.0.1"? >>> Getting lots of these... >>> >>> I've added --trace to xymond_alerts and will go through that. >>> >>> Thanks >>> >>> >>> >>> On Wed, 31 Jan 2024 at 08:32, Jeremy Laidman <jeremy at laidman.org> wrote: >>> >>>> Hi Colin >>>> >>>> From the logs, it appears that xymond_alert is unable to communicate >>>> with your Xymon server on 10.10.10.10:1984. It seems to be trying to >>>> fetch the hosts.cfg file contents via the BB protocol by sending a "config >>>> hosts.cfg" command to xymond, but xymond is not responding. >>>> >>>> The select() system call is monitoring a file handle or socket for >>>> activity, likely the TCP socket with 10.10.10.10:1984. The timeout >>>> means that the select() call didn't return a response in the expected time. >>>> This suggests that the TCP connection was established correctly (xymond is >>>> listening and IP/port are likely correct) and xymond_alert sent the request >>>> for the hosts.cfg file, but there was no response. >>>> >>>> It might be worth checking xymond.log for messages corresponding to the >>>> timestamps of the errors from xymond_alert. >>>> >>>> I'm not convinced this is the reason that you're not getting alert >>>> emails. If xymond_alert can't get hosts.cfg from a BB message, it should be >>>> able to get it directly from the filesystem, and then carry on. So the >>>> messages you're seeing might be a red herring, although I wouldn't >>>> expect them to show up on a normally operating Xymon installation. Having >>>> said that, my Xymon installation is showing those log messages, yet I've no >>>> reason to think that our alerting is broken, so perhaps it's just something >>>> that can be ignored. >>>> >>>> It might be worth taking a look at the man page for xymond_alert, and >>>> have a go at the --test, --trace and --dump-config options. >>>> >>>> In case it's not obvious, I'm really not sure what the problem could >>>> be, and I'm just throwing out some ideas in case something helps. >>>> >>>> J >>>> >>>> On Wed, 31 Jan 2024 at 10:50, Colin Coe <colin.coe at gmail.com> wrote: >>>> >>>>> Hi all >>>>> >>>>> Our Xymon server has recently stopped sending alert emails. This >>>>> server is also running Postfix and is our mail relay. >>>>> >>>>> From alert.log all I see is: >>>>> 2024-01-31 02:17:39.813610 Whoops ! Failed to send message (Select(2) >>>>> failed) >>>>> 2024-01-31 02:17:39.829027 -> Select failure while sending to Xymon >>>>> daemon at 10.10.10.10:1984 >>>>> 2024-01-31 02:17:39.829032 -> Recipient '10.10.10.10', timeout 50 >>>>> 2024-01-31 02:17:39.829037 -> 1st line: 'config hosts.cfg' >>>>> 2024-01-31 02:17:39.829042 Cannot load hosts.cfg from xymond: >>>>> Select(2) failed >>>>> 2024-01-31 02:17:39.829049 Failed to load from xymond, reverting to >>>>> file-load >>>>> 2024-01-31 02:22:40.932828 Whoops ! Failed to send message (Select(2) >>>>> failed) >>>>> 2024-01-31 02:22:40.932863 -> Select failure while sending to Xymon >>>>> daemon at 10.10.10.10:1984 >>>>> 2024-01-31 02:22:40.932867 -> Recipient '10.10.10.10', timeout 50 >>>>> 2024-01-31 02:22:40.932871 -> 1st line: 'config hosts.cfg' >>>>> 2024-01-31 02:22:40.932876 Cannot load hosts.cfg from xymond: >>>>> Select(2) failed >>>>> 2024-01-31 02:22:40.932881 Failed to load from xymond, reverting to >>>>> file-load >>>>> >>>>> And notifications.log is zero bytes in size. >>>>> >>>>> I added "--debug" to the "[alert]" section of /etc/xymon/tasks.cfg and >>>>> while the verbosity was increased, there was no indication of why alerts >>>>> are not being sent. >>>>> >>>>> Any clues how I can debug this? >>>>> >>>>> Thanks >>>>> _______________________________________________ >>>>> Xymon mailing list >>>>> Xymon at xymon.com >>>>> http://lists.xymon.com/mailman/listinfo/xymon >>>>> >>>> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon >> >

1 0

Xymon no longer sending alerts
by colin.coe＠gmail.com 31 Jan '24

31 Jan '24

Hi all Our Xymon server has recently stopped sending alert emails. This server is also running Postfix and is our mail relay. >From alert.log all I see is: 2024-01-31 02:17:39.813610 Whoops ! Failed to send message (Select(2) failed) 2024-01-31 02:17:39.829027 -> Select failure while sending to Xymon daemon at 10.10.10.10:1984 2024-01-31 02:17:39.829032 -> Recipient '10.10.10.10', timeout 50 2024-01-31 02:17:39.829037 -> 1st line: 'config hosts.cfg' 2024-01-31 02:17:39.829042 Cannot load hosts.cfg from xymond: Select(2) failed 2024-01-31 02:17:39.829049 Failed to load from xymond, reverting to file-load 2024-01-31 02:22:40.932828 Whoops ! Failed to send message (Select(2) failed) 2024-01-31 02:22:40.932863 -> Select failure while sending to Xymon daemon at 10.10.10.10:1984 2024-01-31 02:22:40.932867 -> Recipient '10.10.10.10', timeout 50 2024-01-31 02:22:40.932871 -> 1st line: 'config hosts.cfg' 2024-01-31 02:22:40.932876 Cannot load hosts.cfg from xymond: Select(2) failed 2024-01-31 02:22:40.932881 Failed to load from xymond, reverting to file-load And notifications.log is zero bytes in size. I added "--debug" to the "[alert]" section of /etc/xymon/tasks.cfg and while the verbosity was increased, there was no indication of why alerts are not being sent. Any clues how I can debug this? Thanks

3 5

Xymon no longer sending alerts
by colin.coe＠gmail.com 31 Jan '24

31 Jan '24

Hi Kris I've been through the main hosts.cfc and all the included host snippets but found no "funny" characters. Thanks On Wed, 31 Jan 2024 at 08:05, Kris Springer <kspringer at innovateteam.com> wrote: > Looks like your hosts.cfg file has an error in it. This happens to me > sometimes if I'm not careful. Especially if I'm using SSH and scrolling > with my mouse wheel, for some reason it adds weird characters into the > file. > > Kris Springer > > > > On 1/30/24 4:49 PM, Colin Coe wrote: > > Hi all > > Our Xymon server has recently stopped sending alert emails. This server is > also running Postfix and is our mail relay. > > From alert.log all I see is: > 2024-01-31 02:17:39.813610 Whoops ! Failed to send message (Select(2) > failed) > 2024-01-31 02:17:39.829027 -> Select failure while sending to Xymon > daemon at 10.10.10.10:1984 > 2024-01-31 02:17:39.829032 -> Recipient '10.10.10.10', timeout 50 > 2024-01-31 02:17:39.829037 -> 1st line: 'config hosts.cfg' > 2024-01-31 02:17:39.829042 Cannot load hosts.cfg from xymond: Select(2) > failed > 2024-01-31 02:17:39.829049 Failed to load from xymond, reverting to > file-load > 2024-01-31 02:22:40.932828 Whoops ! Failed to send message (Select(2) > failed) > 2024-01-31 02:22:40.932863 -> Select failure while sending to Xymon > daemon at 10.10.10.10:1984 > 2024-01-31 02:22:40.932867 -> Recipient '10.10.10.10', timeout 50 > 2024-01-31 02:22:40.932871 -> 1st line: 'config hosts.cfg' > 2024-01-31 02:22:40.932876 Cannot load hosts.cfg from xymond: Select(2) > failed > 2024-01-31 02:22:40.932881 Failed to load from xymond, reverting to > file-load > > And notifications.log is zero bytes in size. > > I added "--debug" to the "[alert]" section of /etc/xymon/tasks.cfg and > while the verbosity was increased, there was no indication of why alerts > are not being sent. > > Any clues how I can debug this? > > Thanks > > _______________________________________________ > Xymon mailing listXymon at xymon.comhttp://lists.xymon.com/mailman/listinfo/xymon > > >

1 0

Is this thing on? SUMMARY UPDATE and POC
by bruno.manzoni＠ubi-network.ch 29 Jan '24

29 Jan '24

Hi every one *I did a POC on GitHub! *- https://github.com/xymon-monitoring To include/manage the summary of problem (I did previously on this mailing list). The mailing list is not really good to follow problems that take a long time to be resolved (my point of view) This summary also evolve with some more details (but mainly from me) and take a also new form for a better follow up (I hope so) : https://github.com/xymon-monitoring/problem-solving This is only a POC so not official at all, but just for you to see what I did/what could be done (currently limited by my poor skills) You are invited to help me to improve this POC, so to be a member of this GitHub organization: *let me know your GitHub name* Remark: - *Let me know what you think!* - *Focus on the general ideas*: *the support (GitHub)* and *the form* I choose and not to much in the content (I try to make also a good content, but for sure this will need many more work, I would like first to add latest feedback: WIP) - Constructive comment about anything is always welcome! - And as English is not my language: do not hesitate also to correct it. - Positive feedback also motivate... *We still have an urgent problem: the mailing list *(see detail on the POC or in this mailing list) Bruno

4 10

alerts.cfg rules for specific files, libs, ports and procs?
by alt36＠cam.ac.uk 29 Jan '24

29 Jan '24

On 29/01/2024 14:46, Jaap Winius via Xymon wrote: > Hi folks, > > Is it possible to write rules for alerts.cfg that are triggered not by > state changes for services, such as imap or http, but instead for > specific files, libs, ports and procs? If so, what would they look like? The rules used to trigger alerts.cfg are combinations of things like test name, colour, duration, but not the particular contents of a status message. If you just want to alert when the procs test has been red for 5 minutes, that's straightforward: SERVICE=procs COLOR=red DURATION>5 MAIL alert at example.com If you only want to alert based on the actual contents of a status message, I think you'd need to implement a custom SCRIPT as the alert recipient and have it take whatever action you like based upon the content of $BBALPHAMSG . The default alerts.cfg provided with xymon contains a pretty full description of how alerting rules work, in combination with "man alerts.cfg": https://fossies.org/linux/xymon/xymond/etcfiles/alerts.cfg.DIST https://manpages.org/alertscfg/5 Adam

1 0

alerts.cfg rules for specific files, libs, ports and procs?
by jwinius＠umrk.nl 29 Jan '24

29 Jan '24

Hi folks, Is it possible to write rules for alerts.cfg that are triggered not by state changes for services, such as imap or http, but instead for specific files, libs, ports and procs? If so, what would they look like? Thanks, Jaap

1 0

analysis.cfg regular expression
by Neil.Simmonds＠studio.co.uk 17 Jan '24

17 Jan '24

Hi folks, I'm having trouble with a regular expression in a LOG entry in analysis.cfg which is monitoring a Windows log. I've included some sample lines below (IP addresses changed for obvious reasons) and I need to alert when the 12th string (space separated) is 403 (actually 500 but for testing, 403) I've tried this, LOG "%D:\Weblogs\*\u_ex*.log" "%2.{1,75} .{1,75} .{1,75} .{1,75} .{1,75} .{1,75} .{1,75} .{1,75} .{1,75} .{1,75}- 403 .{1,75} .{1,75} .{1,75}" COLOR=yellow And LOG "%D:\Weblogs\*\u_ex*.log" "%(?:\S+\s+){11}403\b" COLOR=yellow 2024-01-16 14:41:01 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 93 2024-01-16 14:42:03 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 83 2024-01-16 14:43:04 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 78 2024-01-16 14:44:08 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 110 2024-01-16 14:45:13 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 89 2024-01-16 14:46:16 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 62 2024-01-16 14:47:20 127.0.0.1 GET / - 80 - 127.0.0.1 Xymon+xymonnet/4.3.30-1.el8.terabithia - 403 14 0 78 Neither of these work. Can anyone help? Kind Regards, Neil. ). Studio is a trading name of Studio Retail Trading Limited (Company no. 03994833), which is an introducer of credit not a lender. Studio Pay is provided by Frasers Group Financial Services Limited (Registered Company no. 00718151), which is authorised and regulated by the Financial Conduct Authority (FRN 311908) for consumer credit and general insurance and a member of the Finance and Leasing Association. Both companies are registered in England and their registered office is: Church Bridge House Henry Street Accrington BB5 4EE. NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. The recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Studio Retail Trading Ltd and Frasers Group Financial Services Ltd reserve the right to monitor all e-mail communications through their internal and external networks. If you have received this email in error please let us know. You can find our available contact details by going to help.studio.co.uk and clicking 'Contact Us'.

2 2