- Xymon - Xymon mailman web

Xymon 4.3.31: review status, and a proposal to release the preview
by Bruno Manzoni 29 Oct '26

29 Oct '26

Hi all, *A short status of the project*, and a *proposal for the 4.3.31 release*. The wiki now has a page of activity numbers, regenerated monthly: https://xymon-monitoring.github.io/xymon-wiki/about/project-activity/ *It shows review is the bottleneck: 81 pull requests wait for an approval, 41 of them for over a month, and four people do 80% of the reviewing.* Anyone may review, no membership needed; running a change on your own system and reporting what it did is a review too. *Getting a change through is hard*, and a pull request with more than a few lines of code hardly moves at all. Many of them are not new ideas: they port fixes that have lived for years in the Debian, Terabithia or devel trees, or sort out build and packaging problems, which nobody enjoys reading. To help with that we put three things in place: - *a regression test suite*, run on every pull request across 47 platform lanes, so a reviewer starts from "it builds and passes everywhere"; - *a pre-review at the end of every pull request*: what the author checked, how, the result, and what is left for the approver, so you read what is left rather than the whole change. Rules in CONTRIBUTING.md; - *an experimental release*, just done: xymon-experimental merges the open pull requests of a milestone on main daily, runs the lanes, and tags a preview when they pass. 4.3.31-preview2 holds the seven still open on 4.3.31 (#349, #428, #579, #646, #682, #684, #687) and passed all 47. The release page says what is in it and where to report what you find; the repository README says how a preview is made and built: https://github.com/xymon-monitoring/xymon-experimental/releases/tag/preview… https://github.com/xymon-monitoring/xymon-experimental#previews The tarball, with its sha256 beside it on the release page: *https://github.com/xymon-monitoring/xymon-experimental/releases/download/preview-4.3.31-2/xymon-4.3.31-preview2.tar.gz* * The install instructions are in the tarball itself, docs/install.html:* the *prerequisites per system* (Debian, RHEL, Fedora, SUSE, Alpine, Arch, the BSDs, macOS, Solaris), the xymon user, configure, make, make install, and the web server. On macOS it is packaged: "brew install xymon-monitoring/xymon/xymon-server-preview". brew install xymon-monitoring/xymon/xymon-server-preview brew services start xymon-server-preview *We need to release.* *I propose to promote the preview2*: merge the seven as they stand in preview2, the code the lanes passed, and cut 4.3.31. That is a bypass on seven changes the merge table says need a review, said so on each, with the lane results as the evidence. If you see a better way, say so: a deadline, people running the preview and reporting on the pull requests, one of the seven held back, or anything else. What I want to avoid is another quarter waiting for a review that does not come. Bruno

1 0

Release notes, install guide, and which version a build should show (#676)
by Bruno Manzoni 26 Oct '26

26 Oct '26

Hi all, Nicola raised three points while reviewing the c-ares change (#138). Two are done, and the third needs your opinion. 1. Release notes. Each pull request now writes its own RELEASENOTES entry (#674), so reviewers and testers see what administrators will be told alongside the change. The 4.3.31 section on main already covers: - client filesystem reporting; - alerting; - page filters; - the web pages; - network tests; - the build, including the switch to the system c-ares and to PCRE2. 19 open pull requests carry theirs. 2. Install guide. docs/install.html was rewritten (#672): - each system has its own package list, with c-ares and PCRE2 named; - it says Xymon no longer ships its own c-ares; - it says 4.3.30 is the last release that builds with the old PCRE. 3. Version shown by a build: comments welcome on the proposal. Every build since 4.3.30 says "Xymon 4.3.30" in its web page footers. That includes builds from main, which already carry everything merged for 4.3.31. The version used to be changed by hand at each release and release candidate, and that stopped. The proposal in https://github.com/xymon-monitoring/xymon/issues/676 makes this automatic, with nothing to do per release: - Released versions and their tarballs show the release number (4.3.31), as today. - Builds from git show where they come from, for example 4.3.31+12.gdef5678, meaning 12 commits after 4.3.31. Where the full form appears: - the page footer; - --version and the status columns of the Xymon programs; - xymond's answer to ping; - a new XYMONBUILD for extension scripts. XYMONDREL and the HTTP tests' User-Agent stay on the release number. One case to check: a client without a clientupdate level sends xymon --version as its clientversion, and the client script compares that exactly with the version the server asks for. It should be harmless, since such servers usually ask for none, but does anything you run rely on it, or compare the other values exactly? The issue lists every place the version appears, and the other approaches considered. If you see a better one, say so. Comments are welcome on the issue or here on the list. Thanks, Nicola, for raising these. Bruno Le 22.10.26 à 11:51, Nicola Canepa a écrit : > > *@canepan* commented on this pull request. > > ------------------------------------------------------------------------ > > In docs/install.html.DIST > <https://github.com/xymon-monitoring/xymon/pull/138#discussion_r4346888131>: > > > @@ -86,7 +86,7 @@ The GNU C compiler works fine on HP-UX. More details in > <a href="http://www.xymon.com/archive/2005/06/msg00079.html">this e-mail</a> from > the Xymon mailing list.</p> > > -<h4>PCRE, RRDtool, OpenSSL, OpenLDAP libraries.</h4> > +<h4>PCRE, RRDtool, c-ares, OpenSSL, OpenLDAP libraries.</h4> > > Nice: I don't understand where this automation is triggered, but I > trust it will work. > Do we have something similar to show the (pre-release) version on the > web pages as it happened in the past (before 4.3.30)? > > — > Reply to this email directly, view it on GitHub > <https://github.com/xymon-monitoring/xymon/pull/138?email_source=notificatio…>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACDOQMHYPW4GPD6TMSE3F2L5V…>. > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/ACDOQMD7U5AMEAFLULYNAE35VHKBTA5…> > and Android > <https://github.com/notifications/mobile/android/ACDOQMASRGXRMEFGP72UOGL5VHK…>. > Download it today! > You are receiving this because you authored the thread.Message ID: > <xymon-monitoring/xymon/pull/138/review/5612328819(a)github.com> >

1 0

Xymon 4.3.31 is close: we need your help to finish it
by Bruno Manzoni 26 Oct '26

26 Oct '26

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+mil… - 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

6 16

Need help with multiple RRD data points in one check
by Christoph Zechner 16 Oct '26

16 Oct '26

Hi, I've stumbled upon a problem I cannot seem to solve myself and hope someone here can help me out... A custom check I wrote is collecting data from Nvidia GPUs via the nvidia-smi command, the check works great and displays all the relevant data in its message, but I want to create graphs from certain data points too. Here's my problem: in a server with 8 GPUs, I am collecting 5 different things from each GPU (like Power Draw, Utilisation and so on), these values get saved in a RRD file as well, but only the values from the first GPU. I want to save a RRD file for each GPU and its values, so multiple data points in a RRD, but 8 different files (one per GPU) and I do not get how I can do this in a xymon check (bash script). Can someone point me in the right direction here? What am I missing? Thanks in advance! Best regards Christoph

5 9

Nobody is watching the repository, including me
by Bruno Manzoni 20 Sep '26

20 Sep '26

Hello everyone, Being a collaborator notifies you of nothing: on GitHub, rights and notifications are unrelated. What subscribes you is the Watch button, and on xymon-monitoring/xymon nobody was using it, myself included. So when Scot opened #521, #522 and #523 last week, GitHub announced them to no one. Three clicks fix that, at the top right of https://github.com/xymon-monitoring/xymon Watch -> Custom -> Pull requests. No membership needed, the repository is public. And if you want to join the organisation, just let us know. Cheers, Bruno

5 9

xymon-rpm pull requests
by Scot Kreienkamp 18 Sep '26

18 Sep '26

Yesterday I closed the two pull requests I opened for the wrong xymon.spec file, and created two new pull requests for the xymon.spec file in the xymon-rpm repo. In short, these are the two issues: * On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. * On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. All tests have passed and they're waiting for review. Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp(a)la-z-boy.com One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com<http://www.la-z-boy.com/> facebook.com/lazboy<http://facebook.com/lazboy> | instagram.com/lazboy<https://instagram.com/lazboy> | youtube.com/lazboy<http://youtube.com/lazboy> [cid:lazboy_2024_inc_navy_4a4d68ec-613a-4141-a2aa-d73a2ae749f6.png] This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

2 1

Review rules, the backlog, and a proposal for when nobody comes
by Bruno Manzoni 17 Sep '26

17 Sep '26

Hello everyone, CONTRIBUTING.md now follows the June conversation on this list — the rules from "The Next Release Is Within Reach" on 16 June, with the condition I added the next morning after the one objection. It also says what the GitHub ruleset really enforces, and on whom. https://github.com/xymon-monitoring/xymon/blob/main/CONTRIBUTING.md It is there because nobody objected in June, not because anyone agreed — say if you disagree and I will change it. The backlog, measured: 53 ready for review (79 open, 26 of them drafts), median 20 days since being marked ready. Nothing is abandoned — none untouched for a fortnight — because I keep rebasing them. And the rate was never the problem: 60 merged between 9 August and 3 September, 51 of them with a review. Then it stopped. Nothing read or reviewed since 30 August, nothing merged since 3 September. To resolve this I propose to add a delay before bypassing a PR: - documentation, tests — 1 week (current 0 days) - build and CI — 2 weeks (current 0 days) - bug fixes — 1 month (current: never) - everything else — 2 months (current: never) The clock runs from when it was marked ready, and any review ends the wait — this is the fallback, not the path. Of the 53, 19 could go in today and the rest within two months with nobody doing anything. The cost: two months means a feature can land unread. The bigger risk runs the other way — a project where finished work cannot move is one that stops. None of it produces a reviewer or a contributor, and that is what we really need. Let me know what you think! Cheers Bruno

4 5

Snapshot feedback
by Scot Kreienkamp 17 Sep '26

17 Sep '26

Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I'm working on deploying a server. * On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. * On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp(a)la-z-boy.com One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com<http://www.la-z-boy.com/> facebook.com/lazboy<http://facebook.com/lazboy> | instagram.com/lazboy<https://instagram.com/lazboy> | youtube.com/lazboy<http://youtube.com/lazboy> [cid:lazboy_2024_inc_navy_4a4d68ec-613a-4141-a2aa-d73a2ae749f6.png] This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

4 12

alternate "Xymon Mailing List Archive" Server
by Bruno Manzoni 17 Sep '26

17 Sep '26

Hi Guys, As Jeremy likes it, let me share some work I did (when repairing the Mailman server earlier this year): An *alternate "**Xymon Mailing List Archive"* Server https://xymon-monitoring.github.io/xymon-discussion-public/ <https://xymon-monitoring.github.io/xymon-discussion-public/> Why I didn't share it earlier: * This does not bring anything the current mailing list does not already provide. What is nice: * Searchable as a first-class feature. * Simple UI, following Xymon's one-click philosophy. * Folded past conversations for easy reading. * Anonymized. * Raw archive of the current mailing list on GitHub. * Hosted entirely on GitHub. What is not nice: * Custom-made: it probably needs more maintenance than Mailman. * It cannot work standalone without Mailman, this cannot replace it (we still need a mailing list server). * 1-day sync (automatic) due to GitHub cron policy (so some latency, acceptable for an archive). Things to do: * Import the SourceForge conversations. There is no plan to push it further for now or to replace the current one. (Let me know if you would like to!) *And also some other information about repository privacy:* Two private repositories are available to Xymon Monitoring members: * |Private|(general information) * |Discussion private|(raw export of Mailman, with private information) → |Discussion public|: generation of the public website Bruno On Thu, 17 Sept 2026 at 12:59, Jeremy Laidman wrote: __ That's brilliant, Bruno! Searchable, and goes all the way back to 2005, in the "Hobbit" days. Nice one! J

1 0

Feedback on using AI/LLMs for Xymon development and reviews
by Bruno Manzoni 14 Sep '26

14 Sep '26

Hi everyone, Here is my feedback on working with AI/LLMs for Xymon: - We no longer code by ourselves; LLMs do it for us. The real skill now is guiding the AI, designing the architecture, and validating the result. LLMs write code better than even experienced C developers, though skilled individuals—including good developers—are still essential to direct them. - We still need to write a specification, like an RFC. - We still need to do reviews to catch problems that a good specification or tests might miss. All this changes the meaning of being a "code author" and shifts how a team should be built. Let me know what you think! Cheers, Bruno

6 7