nexus/ProxMenux
2
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-06-03 13:54:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

menu: self-heal broken monitor unit on launch (belt-and-suspenders for #222)

Browse Source 
The installer fix in this PR rewrites the systemd unit on every
v1.2.2.x update, which catches every user once they accept the
update prompt. But the prompt in `menu` uses `--defaultno` so a
user who presses Enter by reflex stays on the broken state and
opens a fresh issue, which is the scenario unfolding in #222.

Add a tiny `auto_repair_monitor_unit` function that runs before
`check_updates` on every menu launch. It only touches anything when
the bug's exact fingerprint is present:

  1. /etc/systemd/system/proxmenux-monitor.service exists
  2. Its ExecStart points at /usr/local/share/proxmenux/ProxMenux-Monitor.AppImage
  3. The extracted AppRun is already on disk at /usr/local/share/proxmenux/monitor-app/AppRun

When all three are true the function rewrites the unit, reloads
systemd, restarts the service, and logs a single msg_ok line. For
healthy installs and for hosts that never had the Monitor at all,
it returns immediately without touching anything — safe to ship
unconditionally.

Verified on .55 by simulating the broken unit (ExecStart on the
bare AppImage → 203/EXEC + activating loop) and running the new
menu script: unit rewritten to AppRun, service active, single
"ProxMenux Monitor unit repaired and restarted" line printed.

CHANGELOG entries (EN+ES) updated to mention the auto-repair so
users on the broken state know the simpler recovery is now "just
run menu".

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
MacRimi
2026-06-02 20:39:47 +02:00
parent 755c289894
commit 7cea5563a7
3 changed files with 69 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
lang/es/CHANGELOG.md
+2
View File
@@ -5,6 +5,8 @@
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.
El lanzador `menu` se auto-repara además al arrancar: si detecta la huella exacta del bug (la unit con `ExecStart` apuntando al AppImage directo Y el `AppRun` extraído ya presente en disco) reescribe la unit y reinicia el servicio antes de mostrar el aviso de actualización, de modo que un usuario que descarte el update por reflejo termine con el Monitor funcionando.
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)"`.
---