Mirrors/ProxMenux
1
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-06-11 11:06:24 +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

2
CHANGELOG.md
View File

@@ -5,6 +5,8 @@
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.
The `menu` launcher additionally self-heals on startup: if it detects the exact broken fingerprint (unit `ExecStart` pointing at the bare AppImage AND the extracted `AppRun` already present on disk) it rewrites the unit and bounces the service before showing the update prompt, so a user who dismisses the update by reflex still ends up with a working Monitor.
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)"`.
---