v1.2.2.1: rewrite monitor unit on every update to point at AppRun (#222)

The v1.2.2 install layout extracts the AppImage into
/usr/local/share/proxmenux/monitor-app/ and runs AppRun out of that
directory — but install_proxmenux_monitor's update branch only
called create_monitor_service on fresh installs, leaving the inherited
unit's `ExecStart=/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage`
in place. That path used to be the FUSE-mounted AppImage entry point,
which v1.2.2 deliberately replaced to clear a Wazuh rule-521 false
positive on /tmp/.mount_*. On PVE 9.x / Debian 13 the bare AppImage
fails to exec straight away (status=203/EXEC) so the service entered
the activating loop reported in #222 and never came back up.

Always rewrite the unit before the post-update `systemctl start` —
idempotent for installs whose unit is already correct, recovering
for those whose isn't. The new helper
`_proxmenux_rewrite_monitor_unit_for_apprun` mirrors the unit body
the fresh-install path emits in `create_monitor_service`, with the
same template-from-repo / inline-fallback fork, so both paths
converge on the same content.

Reproduced and validated on PVE 9.x lab:

  before:
    Process: ExecStart=/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage
             (code=exited, status=203/EXEC)
    Active: activating (auto-restart)

  after:
    ExecStart=/usr/local/share/proxmenux/monitor-app/AppRun
    Active: active (running)

Bumps version.txt to 1.2.2.1 so the existing menu update path picks
this up automatically. For users already stuck on a broken v1.2.2,
re-running the installer manually applies the same fix:
  bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)"

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
MacRimi
2026-06-02 20:31:33 +02:00
parent 32a3e20c76
commit 17c5b89cc8
4 changed files with 72 additions and 3 deletions
+10
View File
@@ -1,6 +1,16 @@
## 2026-06-02
### Hotfix ProxMenux v1.2.2.1 — *Restore Monitor service after v1.2.1 → v1.2.2 update*
Single-purpose patch for [#222](https://github.com/MacRimi/ProxMenux/issues/222). Users updating from any v1.2.1.x stable installation to v1.2.2 hit a `proxmenux-monitor.service` that refused to start with `status=203/EXEC`. The v1.2.2 install layout extracts the AppImage into `/usr/local/share/proxmenux/monitor-app/` and runs `AppRun` out of that directory — but the installer's update path was reusing whichever unit file was already present and only refreshing the unit on a fresh install, so the inherited unit kept its old `ExecStart=/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage` line. That path used to be a FUSE-mounted AppImage run, which v1.2.2 deliberately moved away from to clear a Wazuh rule-521 false positive on `/tmp/.mount_*`; under PVE 9.x / Debian 13 the bare AppImage failed to exec and the service entered the activating loop. The installer now always rewrites the unit to point at `AppRun` on every update — idempotent for installs whose unit is already correct, recovering for those whose isn't.
To recover an existing broken v1.2.2 install without waiting for the update prompt, run the installer manually once: `bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)"`.
---
## 2026-06-02
### New version ProxMenux v1.2.2 — *Stable consolidation of the v1.2.1.x cycle*
Stable release that brings the four prereleases of the **v1.2.1.x** cycle to the main channel in one move. The work over those four betas centred on three themes: making the Health Monitor genuinely configurable instead of just observable (per-category thresholds, per-event dismiss durations, an audit log of active suppressions), expanding the notification stack to cover roughly 80 services through Apprise while persisting events across Quiet Hours, and turning the Monitor process itself into a quieter, more predictable system citizen on idle hosts. On top of those, this release lands automatic upgrade detection for LXC containers, an end-to-end rewrite of the Coral TPU installer with the latest upstream drivers, and a long list of operator-visible fixes — HTTPS terminal handshake, kernel-update detection on PVE 9.x, NVIDIA installer flow on Alpine LXC, mixed-GPU passthrough audio companion handling, and several runtime optimizations on the Monitor scanning loops. Five direct code contributions from the community ship alongside ([@jcastro](https://github.com/jcastro) ×5, [@pespinel](https://github.com/pespinel) ×1) and the GPU passthrough work was driven by [@ghosthvj](https://github.com/ghosthvj)'s detailed field reports — see the Acknowledgments at the end.
+51 -2
View File
@@ -682,14 +682,25 @@ install_proxmenux_monitor() {
fi
msg_ok "ProxMenux Monitor v$appimage_version installed."
if [ "$service_exists" = false ]; then
return 0 # New installation - service needs to be created
else
# The v1.2.2 install layout extracts the AppImage into
# MONITOR_RUNTIME_DIR/ and runs AppRun out of that directory
# (`extract_appimage_to_runtime_dir` above), so the unit must
# point at AppRun — not at the bare AppImage. Existing users
# updating from v1.2.1.x stable still have a unit whose
# ExecStart targets `/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage`
# which was fine when the AppImage was FUSE-mounted but breaks
# under PVE 9.x / Debian 13 (status=203/EXEC, GitHub issue #222).
# Rewrite the unit on every update — idempotent for users
# whose unit is already correct.
_proxmenux_rewrite_monitor_unit_for_apprun
systemctl start proxmenux-monitor.service
sleep 2
if systemctl is-active --quiet proxmenux-monitor.service; then
update_config "proxmenux_monitor" "updated"
@@ -702,6 +713,44 @@ install_proxmenux_monitor() {
fi
}
# Idempotent rewriter of the proxmenux-monitor unit file. Used by the
# update path in `install_proxmenux_monitor` so that existing
# installations updated to v1.2.2+ get their ExecStart corrected to
# point at the extracted AppRun even when the unit already exists.
# Mirrors `create_monitor_service`'s unit body so both code paths
# converge on the same file content. Returns 0 always; failures are
# logged so the surrounding flow can still attempt the start and
# report a more accurate failure to the user.
_proxmenux_rewrite_monitor_unit_for_apprun() {
local exec_path="$MONITOR_RUNTIME_DIR/AppRun"
if [ -f "$TEMP_DIR/systemd/proxmenux-monitor.service" ]; then
sed "s|ExecStart=.*|ExecStart=$exec_path|g" \
"$TEMP_DIR/systemd/proxmenux-monitor.service" > "$MONITOR_SERVICE_FILE"
else
cat > "$MONITOR_SERVICE_FILE" << EOF
[Unit]
Description=ProxMenux Monitor - Web Dashboard
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=$MONITOR_INSTALL_DIR
ExecStart=$exec_path
Restart=on-failure
RestartSec=10
Environment="PORT=$MONITOR_PORT"
[Install]
WantedBy=multi-user.target
EOF
fi
systemctl daemon-reload
return 0
}
create_monitor_service() {
local exec_path="$MONITOR_RUNTIME_DIR/AppRun"
+10
View File
@@ -1,6 +1,16 @@
## 2026-06-02
### Hotfix ProxMenux v1.2.2.1 — *Restaurar el servicio Monitor tras la actualización v1.2.1 → v1.2.2*
Parche puntual para [#222](https://github.com/MacRimi/ProxMenux/issues/222). Los usuarios que actualizaban desde una instalación v1.2.1.x estable a v1.2.2 se encontraban con un `proxmenux-monitor.service` que no arrancaba con `status=203/EXEC`. El layout de instalación de v1.2.2 extrae el AppImage en `/usr/local/share/proxmenux/monitor-app/` y ejecuta `AppRun` desde ese directorio — pero el path de update del installer reutilizaba la unit file existente y solo refrescaba la unit en instalación nueva, así que la unit heredada conservaba su `ExecStart=/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage` antiguo. Ese path era un AppImage montado por FUSE, algo que v1.2.2 abandonó deliberadamente para eliminar un falso positivo de la regla 521 de Wazuh sobre `/tmp/.mount_*`; bajo PVE 9.x / Debian 13 ejecutar el AppImage directamente fallaba y el servicio entraba en bucle de activación. El installer ahora reescribe la unit para que apunte a `AppRun` en cada update — idempotente para instalaciones cuya unit ya es correcta, recuperando las que no lo son.
Para recuperar una instalación v1.2.2 ya rota sin esperar al aviso de actualización, ejecuta el installer manualmente una vez: `bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)"`.
---
## 2026-06-02
### Nueva versión ProxMenux v1.2.2 — *Consolidación estable del ciclo v1.2.1.x*
Release estable que lleva al canal principal las cuatro prereleases del ciclo **v1.2.1.x** en un solo movimiento. El trabajo a lo largo de esas cuatro betas se centró en tres temas: hacer del Health Monitor algo realmente configurable en lugar de solo observable (thresholds por categoría, duraciones de dismiss por evento, un audit log de supresiones activas), expandir el stack de notificaciones para cubrir alrededor de 80 servicios a través de Apprise mientras se persisten eventos durante las Quiet Hours, y convertir el propio proceso del Monitor en un ciudadano del sistema más silencioso y predecible en hosts idle. Por encima de eso, esta release entrega detección automática de updates en contenedores LXC, una reescritura end-to-end del instalador de Coral TPU con los últimos drivers upstream, y una larga lista de fixes visibles para el operador — handshake del terminal HTTPS, detección de kernel updates en PVE 9.x, flujo del instalador NVIDIA en Alpine LXC, gestión del audio acompañante en passthrough de GPU mixta, y varias optimizaciones runtime en los bucles de scan del Monitor. Cinco contribuciones de código directas de la comunidad shipean junto con esta release ([@jcastro](https://github.com/jcastro) ×5, [@pespinel](https://github.com/pespinel) ×1) y el trabajo de GPU passthrough lo impulsaron los reports detallados de campo de [@ghosthvj](https://github.com/ghosthvj) — ver los Acknowledgments al final.
+1 -1
View File
@@ -1 +1 @@
1.2.2
1.2.2.1