Repository navigation
Conversation
bonomani
added a commit
to bonomani/xymon
that referenced
this pull request
Aug 16, 2026
…itoring#355) xymond has carried oldcolor on its internal channels since forever, and this PR was about to document it as a xymondboard field. It is not one: boardfieldnames[] has no entry for it, so "fields=...,oldcolor" returns an empty column, and xymondlog's default list does not carry it either. Both are selectable now, under names that say when each one moves: prevreportcolor the color at the previous report, assigned every message prevchangecolor the color held before the most recent change The names matter because oldcolor already means the other thing one layer down: in lib/eventlog.h it is the color before a transition, which is what prevchangecolor holds here. A consumer reading both allevents and the board would meet the same word with two meanings. oldcolor and previouscolor stay accepted as aliases -- the names xymond uses internally, and the ones the first consumer of these fields already queries (axians#10) -- the same way matchedtag and matchedtags share a field. prevchangecolor rides the .flapstate. checkpoint record, appended after the flap ring so no position shifts: a reader that predates it stops at its own last case, and a checkpoint written before it restores as "no previous color", which is what those statuses had. The restore path sets it explicitly, next to pregapcolor: calloc leaves 0, which is COL_GREEN, so a file written before the field existed would otherwise restore every test as "was green before" a change it never had. That append is also why xymond-checkpoint-roundtrip.sh changes: it backdated the flap ring through $NF, which now rewrites the new field instead -- and still leaves a line ending in the value written, so the edit read as applied while changing nothing. It names field 11 now. The manual page drops two claims about oldcolor that the code contradicts: that a status whose color has never changed reports "none" (only its first report does; a repeated green reports green), and that the value is the color the test reported (it is the color xymond recorded, which a disable or downtime rewrites).
bonomani
added a commit
to bonomani/xymon
that referenced
this pull request
Aug 16, 2026
…itoring#355) xymond has carried oldcolor on its internal channels since forever, and this PR was about to document it as a xymondboard field. It is not one: boardfieldnames[] has no entry for it, so "fields=...,oldcolor" returns an empty column, and xymondlog's default list does not carry it either. Both are selectable now, under names that say when each one moves: prevreportcolor the color at the previous report, assigned every message prevchangecolor the color held before the most recent change The names matter because oldcolor already means the other thing one layer down: in lib/eventlog.h it is the color before a transition, which is what prevchangecolor holds here. A consumer reading both allevents and the board would meet the same word with two meanings. oldcolor and previouscolor stay accepted as aliases -- the names xymond uses internally, and the ones the first consumer of these fields already queries (axians#10) -- the same way matchedtag and matchedtags share a field. prevchangecolor is checkpointed in a record of its own, following axians#10 rather than riding ".flapstate.": that record is read by position, so a field appended there depends on its write condition and on every reader counting to the same place. An unrecognised ".name." record is skipped instead, so this costs an older xymond nothing, and a checkpoint without it restores as "no previous color" -- which is what those statuses had. The restore path sets that default explicitly, next to pregapcolor: calloc leaves 0, which is COL_GREEN, so a file written before the field existed would otherwise restore every test as "was green before" a change it never had. xymond-checkpoint-roundtrip.sh backdates the flap ring by naming field 11 rather than $NF. Nothing forces that now, but $NF only worked while the ring was last, and it fails silently when it is not: the edit lands on another field and still leaves a line ending in the value written, so the guard passes over an edit that changed nothing. The manual page drops two claims about oldcolor that the code contradicts: that a status whose color has never changed reports "none" (only its first report does; a repeated green reports green), and that the value is the color the test reported (it is the color xymond recorded, which a disable or downtime rewrites).
SoundGoof
force-pushed
the
feature/xymonlive-web
branch
from
August 17, 2026 22:40
e59abca to
42b584b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add Xymon Live web dashboard
Summary
Add a responsive live-status dashboard that queries
xymonddirectly withoutreading history log files.
The dashboard provides:
Server changes
Extend
xymondboardwith:oldcolor, containing the previous reported colorpreviouscolor, containing the color before the latest actual transitionpreviouscolorThese fields let the dashboard distinguish repeated reports from real color
changes.
Integration
xymonlive.cgicgiwrapValidation
./tests/web/xymonlive-dashboard.sh./tests/server/xymondboard-previouscolor.shmake web-buildmake xymond-buildgit diff --check