Hi Mario,

Thanks! Reproduced: if the tree loses its execute bits, configure restores them on its own scripts but not on build/convert-bbservices. That script only converts a 2005 format, so we're removing it. The PR needs a review before it can merge, and it's a two-line diff, so if you have five minutes, I'd love it to be yours: https://github.com/xymon-monitoring/xymon/pull/626

And please report back on SNMP, it's still experimental.

Cheers, Bruno

Le 11.10.2026 à 11:09, hopbyhop.net via Xymon a écrit :

Hi Bruno, hi all. I cloned main tree yesterday and compiled from source as I always used to do with xymon. The box is a Slackware64-current, fping 5.5 and rrd 1.11.0 also compiled from source just before xymon. The only issue I faced was running make install:

make[1]: ../build/convert-bbservices: Permission denied

That was due to convert-bbservices not being executable. I chmod-ed it an re-run make install and all was fine. So far now xymon runs smoothly just as it did before. Then I recompiled with SNMP=1 env and got xymon-snmpcollect executable. I'm planning to start basic SNMP monitoring without devmon on my home network with a few devices: openwrt switches and access points, pfsense firewall, slackware server (it runs xymon and file and media server). I will let you know how xymon's snmp works in my environment.

I'm not sure if I could soon upgrade also the production server at work, running the 4.3.30 release. It would require a pretty big OS refresh first (also Slackware there) and I don't have so much time, since sysadmin is not my role anymore. We started playing with Grafana, but xymon still rocks!

See you soon !!!

Mario De Chenno

Il giorno gio, 08/10/2026 alle 06.46 +0200, Bruno Manzoni via Xymon ha scritto:

...

Hi all,

Seven years after 4.3.30, a new Xymon is nearly ready, and it's a big one:

                         code            tests  docs 241 merged PRs          +5,342 -1,546   +13,266 -2,092 6,497 9 still open            +267 -104       +981 -5         157

Roughly five years of Xymon development, packed into less than one: the biggest Xymon update since 4.3.0.

Help us get it over the line:

• Got time for just one review? Take #349 or #428: they're the ones holding the release back. https://github.com/xymon-monitoring/xymon/pull/349 https://github.com/xymon-monitoring/xymon/pull/428
• Review a 4.3.31 PR. Most of them just wait for a second look: https://github.com/xymon-monitoring/xymon/issues?q=is%3Apr+state%3Aopen+mile...
• Or go shopping in the other open PRs. Something for every taste, and reviewing is free: https://github.com/xymon-monitoring/xymon/pulls
• Build it on your system.
• Run it next to your setup and tell us what changes.

Reply here or open an issue: https://github.com/xymon-monitoring/xymon

Thanks! Bruno

---

Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com

---

Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com

Hi Jeremy

Thanks for testing 4.3.31, and for the report.

1 You're right about ypmatch: on a system without NIS tools, configure printed "ypmatch: command not found" whenever getent did not find the user, and configure.client has the same line. Both now discard ypmatch's errors as they do getent's, and quote the user name for getent like the other two lookups. That's pull request #645, for 4.3.31: https://github.com/xymon-monitoring/xymon/pull/645

The FAILURE itself was correct: configure needs the xymon user to exist before it runs, so creating it first was the right fix on your side.

*->If that works for you, you can review and approve this PR*, and it will be on the rpm package automatically.

2 On SELinux: the spec in the source tarball (rpm/xymon.spec) does no SELinux labelling or policy. That's packaging, handled in the xymon-monitoring/xymon-rpm repository, so i started to work on your findings there:  will be pushed without a review as possible normally in a few minutes (I did not enforce double human review for now): *Nothing to do in your side. *

3. Also I did update the docs with specific RPM/Rhel info...: *Nothing to do in your side. (so shop other feature!)*

Cheers Bruno

Le 12.10.2026 à 08:35, Jeremy Laidman a écrit :

Hi Bruno

I'm testing "4.3.31-root" on RHELv9.8. When I run ./configure I get an error due to ypmatch not being installed:

What userid will be running Xymon [xymon] ?

~/xymon-4.3.31-root/configure.server: line 223: ypmatch: command not found FAILURE: The user xymon does not exist. Create user and try again.

I would guess the ypmatch command STDERR could simply be discarded with "2>/dev/null", as it is already done with getent.

This is probably only cosmetic, and I don't think this is actually going to cause a problem, except that the compilation fails because the xymon user doesn't exist, but that's something I probably should have already done. If I use the configure command line from the spec file, which sets a bunch of variables, I don't see the error message.

I also noticed that the same line in configure.server appears to have an inconsistency in the use of XYMONUSER:

                USERDATA=getent passwd $XYMONUSER 2>/dev/null || ypmatch "${XYMONUSER}" passwd || grep "^${XYMONUSER}:" /etc/passwd

I believe best practice would be to quote "$XYMONUSER" in all three instances, so I'm not sure why it wasn't quoted in the first command.

Ongoing...

I used the spec file to build a package and installed it onto another RHEL9 host. After installation, the only issue I have noticed is that SELinux was preventing CGI scripts from working correctly. I believe the Terabithia RPM package installs a "xymon.pp" file for SELinux to appropriately label the CGI scripts with "httpd_sys_script_exec_t", and also to allow CGI scripts to initiate network connections (required for connecting to localhost:1984).

Apart from that, it all appears to be running correctly, and I'll continue to play with it for a while.

Cheers Jeremy

On Mon, 12 Oct 2026 at 00:03, Bruno Manzoni via Xymon <xymon@xymon.com> wrote:

Hi Mario,

Thanks! Reproduced: if the tree loses its execute bits, configure
restores them on its own scripts but not on
build/convert-bbservices. That script only converts a 2005 format,
so we're removing it. The PR needs a review before it can merge,
and it's a two-line diff, so if you have five minutes, I'd love it
to be yours: https://github.com/xymon-monitoring/xymon/pull/626

And please report back on SNMP, it's still experimental.

Cheers,
Bruno

Le 11.10.2026 à 11:09, hopbyhop.net <http://hopbyhop.net> via
Xymon a écrit :

...

Hi Bruno, hi all.
I cloned main tree yesterday and compiled from source as I always
used to do with xymon.
The box is a Slackware64-current, fping 5.5 and rrd 1.11.0 also
compiled from source just before xymon.
The only issue I faced was running make install:

make[1]: ../build/convert-bbservices: Permission denied

That was due to convert-bbservices not being executable. I
chmod-ed it an re-run make install and all was fine.
So far now xymon runs smoothly just as it did before. Then I
recompiled with SNMP=1 env and got xymon-snmpcollect executable.
I'm planning to start basic SNMP monitoring without devmon on my
home network with a few devices: openwrt switches and access
points, pfsense firewall, slackware server (it runs xymon and
file and media server).
I will let you know how xymon's snmp works in my environment.

I'm not sure if I could soon upgrade also the production server
at work, running the 4.3.30 release. It would require a pretty
big OS refresh first (also Slackware there) and I don't have so
much time, since sysadmin is not my role anymore. We started
playing with Grafana, but xymon still rocks!

See you soon !!!

Mario De Chenno

Il giorno gio, 08/10/2026 alle 06.46 +0200, Bruno Manzoni via
Xymon ha scritto:

...

Hi all,

Seven years after 4.3.30, a new Xymon is nearly ready, and it's
a big one:

                         code            tests      docs
241 merged PRs          +5,342 -1,546   +13,266 -2,092  6,497
9 still open            +267 -104       +981 -5      157

Roughly five years of Xymon development, packed into less than
one: the
biggest Xymon update since 4.3.0.

Help us get it over the line:

- Got time for just one review? Take #349 or #428: they're the ones
holding the release back.
https://github.com/xymon-monitoring/xymon/pull/349
https://github.com/xymon-monitoring/xymon/pull/428
- Review a 4.3.31 PR. Most of them just wait for a second look:
https://github.com/xymon-monitoring/xymon/issues?q=is%3Apr+state%3Aopen+milestone%3A4.3.31
- Or go shopping in the other open PRs. Something for every
taste, and
reviewing is free: https://github.com/xymon-monitoring/xymon/pulls
- Build it on your system.
- Run it next to your setup and tell us what changes.

Reply here or open an issue:
https://github.com/xymon-monitoring/xymon

Thanks!
Bruno

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

_______________________________________________
Xymon mailing list --xymon@xymon.com
To unsubscribe send an email toxymon-leave@xymon.com

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

Hi Jeremy

Thanks for the review. #645 is merged, so the ypmatch fix is on main now.

You were right to suspect your version: "4.3.31-root" isn't 4.3.31. It's an old tag marking where a 4.3.31 branch was started back in 2019, so it is the 4.3.30 code. Main is about 450 commits further on. You can see it in your own report: at that tag the ypmatch line is line 223 of configure.server, but on main it's line 232.

So everything you tested was 4.3.30. The findings still hold, but could you repeat the test on current code? Either:

• clone main: git clone https://github.com/xymon-monitoring/xymon.git
• or install the snapshot RPMs, which are built from main and already include the SELinux labelling. Setup is in https://github.com/xymon-monitoring/xymon-rpm#readme

On VERSION in include/version.h: good catch, and not the wrong thing to complain about. Nothing in our release process updates it today, so as things stand a 4.3.31 release would still say 4.3.30 in xymond's status and on the web pages. It needs to be set as part of the release.

RELEASENOTES: you're looking at main, but the 4.3.31 notes are kept on a separate branch, "Changes", where they're written up as the release gets ready. They already start at 4.3.31: https://github.com/xymon-monitoring/xymon/blob/Changes/RELEASENOTES They're merged into main when the release is cut, so main still starts at 4.3.30 until then.

Cheers Bruno

Le 14.10.2026 à 04:08, Jeremy Laidman via Xymon a écrit :

Thanks Bruno. PR reviewed and approved.

I noticed that in include/version.h VERSION is still set to 4.3.30. Should this be bumped to 4.3.31-RC or something like that?

I have to admit that I don't really understand much about Github and CI/CD and dev workflows, so I may be complaining about the wrong thing. It might also be possible that I'm testing an older version of Xymon! I suspect this is not the case, because I downloaded the one tagged 4.3.31-root, and the xymon.spec file shows "Version: 4.3.31".

So it might be the case that it's not appropriate to change VERSION at this time.

Similarly, should the RELEASENOTES be updated? Currently it starts with 4.3.30 and goes backward. But again, this might be the last thing to be updated after testing is complete?

J

On Mon, 12 Oct 2026 at 22:01, Bruno Manzoni via Xymon <xymon@xymon.com> wrote:

Hi Jeremy

Thanks for testing 4.3.31, and for the report.

1 You're right about ypmatch: on a system without NIS tools,
configure printed "ypmatch: command not found" whenever getent did
not find the user, and configure.client has the same line. Both
now discard ypmatch's errors as they do getent's, and quote the
user name for getent like the other two lookups. That's pull
request #645, for 4.3.31:
https://github.com/xymon-monitoring/xymon/pull/645

The FAILURE itself was correct: configure needs the xymon user to
exist before it runs, so creating it first was the right fix on
your side.

*->If that works for you, you can review and approve this PR*, and
it will be on the rpm package automatically.

2 On SELinux: the spec in the source tarball (rpm/xymon.spec) does
no SELinux labelling or policy. That's packaging, handled in the
xymon-monitoring/xymon-rpm repository, so i started to work on
your findings there:  will be pushed without a review as possible
normally in a few minutes (I did not enforce double human review
for now): *Nothing to do in your side. *

3. Also I did update the docs with specific RPM/Rhel info...:
*Nothing to do in your side. (so shop other feature!)*

Cheers
Bruno

Le 12.10.2026 à 08:35, Jeremy Laidman a écrit :

...

Hi Bruno

I'm testing "4.3.31-root" on RHELv9.8. When I run ./configure I
get an error due to ypmatch not being installed:

What userid will be running Xymon [xymon] ?

~/xymon-4.3.31-root/configure.server: line 223: ypmatch: command
not found
FAILURE: The user xymon does not exist. Create user and try again.

I would guess the ypmatch command STDERR could simply be
discarded with "2>/dev/null", as it is already done with getent.

This is probably only cosmetic, and I don't think this is
actually going to cause a problem, except that the compilation
fails because the xymon user doesn't exist, but that's something
I probably should have already done. If I use the configure
command line from the spec file, which sets a bunch of variables,
I don't see the error message.

I also noticed that the same line in configure.server appears to
have an inconsistency in the use of XYMONUSER:

                USERDATA=`getent passwd $XYMONUSER 2>/dev/null ||
ypmatch "${XYMONUSER}" passwd || grep "^${XYMONUSER}:" /etc/passwd`

I believe best practice would be to quote "$XYMONUSER" in all
three instances, so I'm not sure why it wasn't quoted in the
first command.

Ongoing...

I used the spec file to build a package and installed it onto
another RHEL9 host. After installation, the only issue I have
noticed is that SELinux was preventing CGI scripts from working
correctly. I believe the Terabithia RPM package installs a
"xymon.pp" file for SELinux to appropriately label the CGI
scripts with "httpd_sys_script_exec_t", and also to allow CGI
scripts to initiate network connections (required for connecting
to localhost:1984).

Apart from that, it all appears to be running correctly, and I'll
continue to play with it for a while.

Cheers
Jeremy

On Mon, 12 Oct 2026 at 00:03, Bruno Manzoni via Xymon
<xymon@xymon.com> wrote:

    Hi Mario,

    Thanks! Reproduced: if the tree loses its execute bits,
    configure restores them on its own scripts but not on
    build/convert-bbservices. That script only converts a 2005
    format, so we're removing it. The PR needs a review before it
    can merge, and it's a two-line diff, so if you have five
    minutes, I'd love it to be yours:
    https://github.com/xymon-monitoring/xymon/pull/626

    And please report back on SNMP, it's still experimental.

    Cheers,
    Bruno

    Le 11.10.2026 à 11:09, hopbyhop.net <http://hopbyhop.net> via
    Xymon a écrit :

...

    Hi Bruno, hi all.
    I cloned main tree yesterday and compiled from source as I
    always used to do with xymon.
    The box is a Slackware64-current, fping 5.5 and rrd 1.11.0
    also compiled from source just before xymon.
    The only issue I faced was running make install:

    make[1]: ../build/convert-bbservices: Permission denied

    That was due to convert-bbservices not being executable. I
    chmod-ed it an re-run make install and all was fine.
    So far now xymon runs smoothly just as it did before. Then I
    recompiled with SNMP=1 env and got xymon-snmpcollect executable.
    I'm planning to start basic SNMP monitoring without devmon
    on my home network with a few devices: openwrt switches and
    access points, pfsense firewall, slackware server (it runs
    xymon and file and media server).
    I will let you know how xymon's snmp works in my environment.

    I'm not sure if I could soon upgrade also the production
    server at work, running the 4.3.30 release. It would require
    a pretty big OS refresh first (also Slackware there) and I
    don't have so much time, since sysadmin is not my role
    anymore. We started playing with Grafana, but xymon still rocks!

    See you soon !!!

    Mario De Chenno

    Il giorno gio, 08/10/2026 alle 06.46 +0200, Bruno Manzoni
    via Xymon ha scritto:

...

    Hi all,

    Seven years after 4.3.30, a new Xymon is nearly ready, and
    it's a big one:

                             code tests           docs
    241 merged PRs          +5,342 -1,546  +13,266 -2,092  6,497
    9 still open            +267 -104  +981 -5         157

    Roughly five years of Xymon development, packed into less
    than one: the
    biggest Xymon update since 4.3.0.

    Help us get it over the line:

    - Got time for just one review? Take #349 or #428: they're
    the ones
    holding the release back.
    https://github.com/xymon-monitoring/xymon/pull/349
    https://github.com/xymon-monitoring/xymon/pull/428
    - Review a 4.3.31 PR. Most of them just wait for a second
    look:
    https://github.com/xymon-monitoring/xymon/issues?q=is%3Apr+state%3Aopen+milestone%3A4.3.31
    - Or go shopping in the other open PRs. Something for every
    taste, and
    reviewing is free:
    https://github.com/xymon-monitoring/xymon/pulls
    - Build it on your system.
    - Run it next to your setup and tell us what changes.

    Reply here or open an issue:
    https://github.com/xymon-monitoring/xymon

    Thanks!
    Bruno

    _______________________________________________
    Xymon mailing list -- xymon@xymon.com
    To unsubscribe send an email to xymon-leave@xymon.com

    _______________________________________________
    Xymon mailing list --xymon@xymon.com
    To unsubscribe send an email toxymon-leave@xymon.com

    _______________________________________________
    Xymon mailing list -- xymon@xymon.com
    To unsubscribe send an email to xymon-leave@xymon.com

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

---

Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com

Hi, sorry to be late on the train. I am trying to review some of the PRs, and I think it would be useful (at least for me):

• an hint on how to checkout (if at all possible) PRs without the gh CLI
• since we started using docker at least for tests, is there a guide on how to spin it up for local tests (from a local checkout, so to test PRs)?

I admit I didn't use GH much, because I prefer my local git repos (backed up also in GH and GL), these may be trivial questions/problems.

I will continue reviewing to the best of my possibilities, but I think addressing the above could ease the path for new contributors.

My first issue is this: I run a basic build with the stable tree, and I succeeded to install it. I then checked out a PR with gh pr checkout 585 and the build attempt failed with:

In file included from /home/nicola/Documents/dev/xymon/include/libxymon.h:81, from cgi.c:24: /home/nicola/Documents/dev/xymon/include/../lib/loadalerts.h:20:10: fatal error: pcre2.h: File o directory non esistente 20 | #include <pcre2.h> | ^~~~~~~~~

I remember switching to more modern PCRE, but this also means PRs are based on a new branch which should be checked out as a baseline before attempting new builds, right?

Nicola

Il giorno dom 18 ott 2026 alle ore 12:23 Roland Rosenfeld via Xymon < xymon@xymon.com> ha scritto:

On Do, 08 Okt 2026, Bruno Manzoni via Xymon wrote:

...

Seven years after 4.3.30, a new Xymon is nearly ready, and it's a big one:

                    code            tests           docs

241 merged PRs +5,342 -1,546 +13,266 -2,092 6,497 9 still open +267 -104 +981 -5 157

Ten days later we still have 9 PRs open for 4.3.31 (okay, #661 should be trivial to approve and I just approved #636), but I fear we won't ever reach the point where all PRs for milestone 4.3.31 are merged.

I thought about reviewing the remaining 7 PRs, but I fear my C skills are too limited for this... So maybe we should just release 4.3.31 as it is now and move the open PRs to 4.3.32.

...

From my point of view the current 4.3.31 HEAD is much better than seven year old 4.3.30 (also without the last PRs applied) and would be a big step forward for all users.

At least for me as Debian maintainer of the package an early release would make life easier since it would be the end of trying to keep old 4.3.30 alive in Debian while in parallel try to keep/merge all changes from the 241 merged PRs into an upcoming Debian package. A fixed milestone, which I could release in Debian would make this much easier...

So what is really missing to release 4.3.31? Add the latest changes to Changes branch (update Changes and RELEASENOTES) and merge them into the main branch and then just do the release process...

I's suggest doing so sooner than later. And after this do a restart with 4.3.32.

Greetings Roland

---

Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com

Hi Nicola!

On Mon, 19 Oct 2026, Nicola wrote:

• an hint on how to checkout (if at all possible) PRs without the gh CLI

I usually use the github web GUI. If I need a patch (for example from PR 668), just append ".patch" to the PR URL and you get one: https://github.com/xymon-monitoring/xymon/pull/668.patch Okay, that's not a perfect GIT workflow, but for my use case (adding them to the Debian source package using quilt) it's what I need.

I will continue reviewing to the best of my possibilities, but I think addressing the above could ease the path for new contributors.

I fear that there are as many different workflows as contributors :-)

On Mo, 19 Okt 2026, Nicola wrote:

Now answering to myself. I see there is no mention anywhere on how to install the pcre2 packages on debian (a git grep apt.*pcre2 shows nothing useful). Is it worth adding it along with the yum docs?

That depends who you address with this. I as a Debian developer don't need this info ;-) On Debian installing pcre2 build libraries can be done with apt install libpcre2-dev

Maybe you should have a lookg at .github/workflows/build.yml, which gives hints how to install build dependencies:

sudo apt-get update sudo apt-get install -y --no-install-recommends
build-essential
libc-ares-dev
libldap-dev
libpcre2-dev
librrd-dev
libssl-dev
libtirpc-dev

as well as for building:

env USEXYMONPING=y
ENABLESSL=y
ENABLELDAP=y
ENABLELDAPSSL=y
XYMONUSER=xymon
XYMONTOPDIR=/usr/lib/xymon
XYMONVAR=/var/lib/xymon
XYMONHOSTURL=/xymon
CGIDIR=/usr/lib/xymon/cgi-bin
XYMONCGIURL=/xymon-cgi
SECURECGIDIR=/usr/lib/xymon/cgi-secure
SECUREXYMONCGIURL=/xymon-seccgi
HTTPDGID=www-data
XYMONLOGDIR=/var/log/xymon
XYMONHOSTNAME=localhost
XYMONHOSTIP=127.0.0.1
MANROOT=/usr/share/man
INSTALLBINDIR=/usr/lib/xymon/server/bin
INSTALLETCDIR=/etc/xymon
INSTALLWEBDIR=/etc/xymon/web
INSTALLEXTDIR=/usr/lib/xymon/server/ext
INSTALLTMPDIR=/var/lib/xymon/tmp
INSTALLWWWDIR=/var/lib/xymon/www
./configure --server make

(to the other questions I don't have answers).

Greetings Roland

Hi Nicola

Thanks for reviewing, and welcome aboard. Taking your points in order:

*1. Checking out a PR without gh:*

    git fetch origin pull/585/head:pr-585 git checkout pr-585

Roland's .patch trick works too. Note that I rebased all the open PRs on current main yesterday, so if you already have pr-585, fetch it again:

    git fetch origin pull/585/head git checkout -B pr-585 FETCH_HEAD

*2. Docker: *there's nothing in the main repo yet, but my fork has an experimental setup on the cmake/bootstrap branch. It builds the tree inside a distro image and installs it there. To try it on a PR:

    git remote add bonomani https://github.com/bonomani/xymon.git git fetch bonomani cmake/bootstrap git checkout pr-585 git checkout bonomani/cmake/bootstrap -- docker ci docker build -f docker/Dockerfile --build-arg BASE_IMAGE=debian:12 --build-arg BUILD_TOOL=make -t xymon-pr585 .

To run the test suite in that image:

    docker run --rm xymon-pr585 bash -c 'cd /src && XYMON_VARIANT=server ./tests/testsuite'

And to start the installed Xymon and query it (for #585, the last line should print 0):

    docker run --rm xymon-pr585 bash -c ' set -e cp -a /tmp/xymon-stage/var/. /var/ mkdir -p /var/log/xymon chown -R xymon:xymon /var/lib/xymon /var/log/xymon su xymon -s /bin/sh -c "/var/lib/xymon/server/bin/xymon.sh start" X=/var/lib/xymon/server/bin/xymon for i in $(seq 30); do $X 127.0.0.1 ping && break; sleep 1; done $X 127.0.0.1 "config hosts.cfg" | tr -cd "\000" | wc -c'

I tested all of this on #585 with Debian 12, on amd64 and arm64: 118 tests pass, Xymon starts, and the reply has no NUL bytes. "git reset --hard" takes you back to the plain PR afterwards.

*3. Dependencies:* you're right that the docs are behind: install.html still lists the old pcre-devel. #672 fixes that, with a current command for Debian and other common systems. On Debian it's:

    apt-get install build-essential libc-ares-dev libldap-dev libpcre2-dev librrd-dev libssl-dev libtirpc-dev

It's a draft until #138 and #349 merge, but a review is very welcome: https://github.com/xymon-monitoring/xymon/pull/672

And no, there's no separate base branch: main switched to PCRE2 after 4.3.30, so libpcre2-dev was all you were missing.

*4. Verifying #585:* the bug is NUL bytes in xymond's reply to "config hosts.cfg". Every host listed after the bad line loses alerts and client analysis, while the web page still shows it. Two things trigger it: - an empty "optional directory" line, every time; - an "include" of a missing file, but only when the line has trailing whitespace.

To see it, compare main and the PR:

    xymon 127.0.0.1 "config hosts.cfg" | od -c | grep '\\0'

On main you should get NUL bytes, and the hosts after that line are missing from the reply. With #585 there are no NULs and every host is there. The shipped hosts.cfg ends with an "optional directory" line, so a fresh install like the Docker one above already shows the difference. If you used a "directory" line pointing to a missing directory, that's the one path the PR didn't test, so a report on it would be very welcome.

*5. make clean: *confirmed. It doesn't clean the bundled c-ares under xymonnet/c-ares, so the x86_64 objects survive. Use "make distclean" when you change architecture. #138 removes the bundled copy and builds against the system c-ares, so the problem goes away when it merges. It's waiting for review if you want another one: https://github.com/xymon-monitoring/xymon/pull/138

Cheers

Bruno

Le 19.10.26 à 19:25, Nicola via Xymon a écrit :

I figured out what I need: I was thinking more to make it easier for everyone. Thanks for the shortcut to avoid answering all questions at every attempt.

Another thing I noticed is that the "make clean" command is not actually cleaning up everything: moving from x86_64 to aarch64, I had to delete all .a files, together with the .lo ones

Nicola

Il giorno lun 19 ott 2026 alle ore 16:04 Roland Rosenfeld <roland@spinnaker.de> ha scritto:

Hi Nicola!

On Mon, 19 Oct 2026, Nicola wrote:

> * an hint on how to checkout (if at all possible) PRs without the gh
>   CLI

I usually use the github web GUI.  If I need a patch (for example from
PR 668), just append ".patch" to the PR URL and you get one:
https://github.com/xymon-monitoring/xymon/pull/668.patch
Okay, that's not a perfect GIT workflow, but for my use case (adding
them to the Debian source package using quilt) it's what I need.

> I will continue reviewing to the best of my possibilities, but I
> think addressing the above could ease the path for new contributors.

I fear that there are as many different workflows as contributors :-)

On Mo, 19 Okt 2026, Nicola wrote:

> Now answering to myself.
> I see there is no mention anywhere on how to install the pcre2
packages on
> debian (a git grep apt.*pcre2 shows nothing useful).
> Is it worth adding it along with the yum docs?

That depends who you address with this.  I as a Debian developer don't
need this info ;-)
On Debian installing pcre2 build libraries can be done with
 apt install libpcre2-dev

Maybe you should have a lookg at .github/workflows/build.yml, which
gives hints how to install build dependencies:

sudo apt-get update
          sudo apt-get install -y --no-install-recommends \
            build-essential \
            libc-ares-dev \
            libldap-dev \
            libpcre2-dev \
            librrd-dev \
            libssl-dev \
            libtirpc-dev

as well as for building:

env USEXYMONPING=y \
          ENABLESSL=y \
          ENABLELDAP=y \
          ENABLELDAPSSL=y \
          XYMONUSER=xymon \
          XYMONTOPDIR=/usr/lib/xymon \
          XYMONVAR=/var/lib/xymon \
          XYMONHOSTURL=/xymon \
          CGIDIR=/usr/lib/xymon/cgi-bin \
          XYMONCGIURL=/xymon-cgi \
          SECURECGIDIR=/usr/lib/xymon/cgi-secure \
          SECUREXYMONCGIURL=/xymon-seccgi \
          HTTPDGID=www-data \
          XYMONLOGDIR=/var/log/xymon \
          XYMONHOSTNAME=localhost \
          XYMONHOSTIP=127.0.0.1 \
          MANROOT=/usr/share/man \
          INSTALLBINDIR=/usr/lib/xymon/server/bin \
          INSTALLETCDIR=/etc/xymon \
          INSTALLWEBDIR=/etc/xymon/web \
          INSTALLEXTDIR=/usr/lib/xymon/server/ext \
          INSTALLTMPDIR=/var/lib/xymon/tmp \
          INSTALLWWWDIR=/var/lib/xymon/www \
          ./configure --server
make

(to the other questions I don't have answers).

Greetings
Roland

---

Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com

Hi Nicola

Yes, log grepping is part of it.

"Client analysis" is the server turning a client's raw report into the cpu, disk, memory, procs, msgs (log matching), files and ports columns, using the rules in analysis.cfg. It always runs on the server, whichever client sends the report: the one installed with the server or a standalone one. The only exception is a client in --local mode, which does its own analysis and isn't affected.

With the bug, the analysis can't see the hosts listed after the bad line, so it silently drops their reports. Their client columns never appear, or go purple if they existed, and they get no alerts. The web page still lists them with their network tests, because it reads hosts.cfg straight from disk. That's why it's easy to miss.

I reproduced all of this on a test server built from main before #585.

Cheers

Bruno

Le 21.10.26 à 11:56, Nicola via Xymon a écrit :

I read the PR description, but I am not sure what "client analysis" means: what would be missing from the web rendering? Is it log grepping for example?

Nicola

Il giorno mar 20 ott 2026 alle ore 06:24 Bruno Manzoni via Xymon <xymon@xymon.com> ha scritto:

Hi Nicola

Thanks for reviewing, and welcome aboard. Taking your points in order:

*1. Checking out a PR without gh:*

    git fetch origin pull/585/head:pr-585
    git checkout pr-585

Roland's .patch trick works too. Note that I rebased all the open
PRs on
current main yesterday, so if you already have pr-585, fetch it again:

    git fetch origin pull/585/head
    git checkout -B pr-585 FETCH_HEAD

*2. Docker: *there's nothing in the main repo yet, but my fork has an
experimental setup on the cmake/bootstrap branch. It builds the tree
inside a distro image and installs it there. To try it on a PR:

    git remote add bonomani https://github.com/bonomani/xymon.git
    git fetch bonomani cmake/bootstrap
    git checkout pr-585
    git checkout bonomani/cmake/bootstrap -- docker ci
    docker build -f docker/Dockerfile --build-arg
BASE_IMAGE=debian:12 --build-arg BUILD_TOOL=make -t xymon-pr585 .

To run the test suite in that image:

    docker run --rm xymon-pr585 bash -c 'cd /src &&
XYMON_VARIANT=server ./tests/testsuite'

And to start the installed Xymon and query it (for #585, the last line
should print 0):

    docker run --rm xymon-pr585 bash -c '
      set -e
      cp -a /tmp/xymon-stage/var/. /var/
      mkdir -p /var/log/xymon
      chown -R xymon:xymon /var/lib/xymon /var/log/xymon
      su xymon -s /bin/sh -c "/var/lib/xymon/server/bin/xymon.sh
start"
      X=/var/lib/xymon/server/bin/xymon
      for i in $(seq 30); do $X 127.0.0.1 ping && break; sleep 1; done
      $X 127.0.0.1 "config hosts.cfg" | tr -cd "\000" | wc -c'

I tested all of this on #585 with Debian 12, on amd64 and arm64: 118
tests pass, Xymon starts, and the reply has no NUL bytes. "git reset
--hard" takes you back to the plain PR afterwards.

*3. Dependencies:* you're right that the docs are behind: install.html
still lists the old pcre-devel. #672 fixes that, with a current
command
for Debian and other common systems. On Debian it's:

    apt-get install build-essential libc-ares-dev libldap-dev
libpcre2-dev librrd-dev libssl-dev libtirpc-dev

It's a draft until #138 and #349 merge, but a review is very welcome:
https://github.com/xymon-monitoring/xymon/pull/672

And no, there's no separate base branch: main switched to PCRE2 after
4.3.30, so libpcre2-dev was all you were missing.

*4. Verifying #585:* the bug is NUL bytes in xymond's reply to
"config hosts.cfg". Every host listed after the bad line loses
alerts and
client analysis, while the web page still shows it. Two things trigger
it:
  - an empty "optional directory" line, every time;
  - an "include" of a missing file, but only when the line has
trailing
    whitespace.

To see it, compare main and the PR:

    xymon 127.0.0.1 "config hosts.cfg" | od -c | grep '\\0'

On main you should get NUL bytes, and the hosts after that line are
missing from the reply. With #585 there are no NULs and every host is
there. The shipped hosts.cfg ends with an "optional directory"
line, so a
fresh install like the Docker one above already shows the
difference. If
you used a "directory" line pointing to a missing directory,
that's the
one path the PR didn't test, so a report on it would be very welcome.

*5. make clean: *confirmed. It doesn't clean the bundled c-ares under
xymonnet/c-ares, so the x86_64 objects survive. Use "make
distclean" when
you change architecture. #138 removes the bundled copy and builds
against
the system c-ares, so the problem goes away when it merges. It's
waiting
for review if you want another one:
https://github.com/xymon-monitoring/xymon/pull/138

Cheers

Bruno


Le 19.10.26 à 19:25, Nicola via Xymon a écrit :

...

I figured out what I need: I was thinking more to make it easier
for everyone.
Thanks for the shortcut to avoid answering all questions at every
attempt.

Another thing I noticed is that the "make clean" command is not
actually cleaning up everything: moving from x86_64 to aarch64, I
had to delete all .a files, together with the .lo ones


Nicola


Il giorno lun 19 ott 2026 alle ore 16:04 Roland Rosenfeld
<roland@spinnaker.de> ha scritto:

    Hi Nicola!

    On Mon, 19 Oct 2026, Nicola wrote:

    > * an hint on how to checkout (if at all possible) PRs
    without the gh
    >   CLI

    I usually use the github web GUI.  If I need a patch (for
    example from
    PR 668), just append ".patch" to the PR URL and you get one:
    https://github.com/xymon-monitoring/xymon/pull/668.patch
    Okay, that's not a perfect GIT workflow, but for my use case
    (adding
    them to the Debian source package using quilt) it's what I need.

    > I will continue reviewing to the best of my possibilities,
    but I
    > think addressing the above could ease the path for new
    contributors.

    I fear that there are as many different workflows as
    contributors :-)

    On Mo, 19 Okt 2026, Nicola wrote:

    > Now answering to myself.
    > I see there is no mention anywhere on how to install the
    pcre2 packages on
    > debian (a git grep apt.*pcre2 shows nothing useful).
    > Is it worth adding it along with the yum docs?

    That depends who you address with this.  I as a Debian
    developer don't
    need this info ;-)
    On Debian installing pcre2 build libraries can be done with
     apt install libpcre2-dev

    Maybe you should have a lookg at .github/workflows/build.yml,
    which
    gives hints how to install build dependencies:

    sudo apt-get update
              sudo apt-get install -y --no-install-recommends \
                build-essential \
                libc-ares-dev \
                libldap-dev \
                libpcre2-dev \
                librrd-dev \
                libssl-dev \
                libtirpc-dev

    as well as for building:

    env USEXYMONPING=y \
              ENABLESSL=y \
              ENABLELDAP=y \
              ENABLELDAPSSL=y \
              XYMONUSER=xymon \
              XYMONTOPDIR=/usr/lib/xymon \
              XYMONVAR=/var/lib/xymon \
              XYMONHOSTURL=/xymon \
              CGIDIR=/usr/lib/xymon/cgi-bin \
              XYMONCGIURL=/xymon-cgi \
              SECURECGIDIR=/usr/lib/xymon/cgi-secure \
              SECUREXYMONCGIURL=/xymon-seccgi \
              HTTPDGID=www-data \
              XYMONLOGDIR=/var/log/xymon \
              XYMONHOSTNAME=localhost \
              XYMONHOSTIP=127.0.0.1 \
              MANROOT=/usr/share/man \
              INSTALLBINDIR=/usr/lib/xymon/server/bin \
              INSTALLETCDIR=/etc/xymon \
              INSTALLWEBDIR=/etc/xymon/web \
              INSTALLEXTDIR=/usr/lib/xymon/server/ext \
              INSTALLTMPDIR=/var/lib/xymon/tmp \
              INSTALLWWWDIR=/var/lib/xymon/www \
              ./configure --server
    make

    (to the other questions I don't have answers).

    Greetings
    Roland


_______________________________________________
Xymon mailing list --xymon@xymon.com
To unsubscribe send an email toxymon-leave@xymon.com

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

---

Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com