Skip to content

v2.0.1 — the CPU line that never fired

Latest

Choose a tag to compare

@amayer1983 amayer1983 released this 04 Aug 12:56

Two fixes, both from @NotRetarded in #2, who caught another Unifi-OS-Server crash and sent me the alert it produced.

Crash alerts never reported host CPU load

His container died with exit 137 during a docker compose install. Memory was nowhere near the problem — 4.4 of 7.6 GB, largest container 253 MiB — and the alert carried no CPU line at all.

The cause isn't a threshold set too high. docker stats reports containers, and what was burning the processor was the daemon unpacking layers. An image pull, a compose build, a backup job, any host process — none of it is visible to us, so the line went quiet in exactly the situation it exists for.

Memory has had the right shape since v1.65.0: the host reading first, answering was the machine under pressure at all, and only then the per-container list. CPU never got its half. It does now:

🔁 Unifi-OS-Server crashed (exit 137) … (restart #4).
Host memory (used/total): 4.4/7.6 GB · Swap 1.5/29.3 GB
Host load (1 min / cores): 11.82 / 4
Top memory at event time: Dockge 253.2MiB · Jellyfin 227.9MiB · …

/proc/loadavg inside a container reports the host's run queue, the same way /proc/meminfo reports host memory — measured, both identical to the values outside. Deliberately not gated on a threshold: a low number answers the question as well as a high one, and gating is what made the container-level line useless here. Same locality guard as the memory line, so a monitor watching a remote host stays silent rather than reporting the wrong machine.

If you have ever seen exit 137 with plenty of memory free, this is the reading that tells you whether it was contention. Measured in v1.65.0: the same container with the same shutdown handler exits 0 on a full CPU and 137 at --cpus=0.005, with OOMKilled false — byte-identical to a kernel OOM kill.

The Stop button looked latched

The container row used one visual language for two meanings. Stop wore a filled red button, while the auto and major-confirm toggles use colour to mean this switch is ON — so Stop read as a switch someone had left on. It carries the same neutral border as the other momentary buttons now; 🛑 says what it is without help. Same red-on-red that came off every other button in v1.73.0, this one was simply missed.


Upgrading is the usual docker pull ghcr.io/amayer1983/docksentry:latest, or nothing at all with auto-selfupdate on.