Add repair/cleanup script for half-installed RMM and Zabbix hosts - #2
Merged
Merged
Conversation
Diagnoses and repairs a client server left in a partial state by an interrupted or failed TacticalRMM agent or Zabbix Agent 2 install, and can strip either stack back to nothing so a clean install can follow. It never installs an agent — the existing installers do that. Detects, for the RMM agent: binary present but never registered, config present with the binary missing, a missing or orphaned systemd unit, a failed service, an empty /opt/tacticalmesh left by a failed mesh install, and stale build leftovers in /tmp. For Zabbix: a half-installed package, a broken dpkg state, the legacy v1 agent alongside Agent 2 (they conflict on port 10050), a config missing Server/ServerActive/Hostname, a missing plugins.d Include, CHANGE_ME placeholder credentials, the apt repo added without the agent, and the classic crash loop — a plugin config referencing a loadable plugin whose package is not installed. repair reconciles a broken dpkg state, recreates the tacticalagent unit, starts services that should be running, disables orphaned plugin configs, adds the missing Include, and clears build leftovers. Anything it cannot fix safely is reported with a next step. Safety: report is the default and is read-only, exiting 0 when healthy/absent and 1 when problems are found so it doubles as a TacticalRMM check. Destructive actions back up all configuration to /var/backups first, refuse to touch a stack that looks healthy unless "force" is given, and refuse to run non-interactively without an explicit "yes" — a stray scheduled run must not wipe a working agent. Interactive runs require typing REMOVE. Uses set -uo pipefail with explicit || die / || warn rather than -e, matching the TRMM installer and updater: on a broken host a probe returning non-zero is normal input, not a failure. Tested in Debian 12 containers — 9 scenarios, 29 assertions, all passing, plus 5/5 on the healthy-stack guard. Service-restart paths and the healthy state itself still need a host with a live systemd.
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 2, 2026
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Stacked on #1 (base is
trmm-linux-no-mesh, so this shows only its own commit). GitHub will retarget it tomainautomatically once #1 merges.What this is
repair-rmm-zabbix-linux.sh— diagnoses and repairs a client server left half-installed by an interrupted or failed TacticalRMM agent or Zabbix Agent 2 install, and can strip either stack back to nothing so a clean install can follow.It never installs either agent. That stays with
install-tacticalrmm-agent-linux.shandinstall-zabbix-agent-linux-tactical-rmm.sh; this script's job is to get a messy host back to a known state so those can run cleanly.Actions
report0= healthy/absent,1= problems found — so it doubles as a TacticalRMM checkrepairclean-trmm/clean-zabbix/clean-allWhat it detects
RMM agent: binary present but never registered · config present with the binary missing · missing or orphaned systemd unit · failed service · an empty
/opt/tacticalmeshleft by a failed mesh install (exactly the wreckage the bug in #1 produced) · stale build leftovers in/tmp.Zabbix: half-installed package · broken dpkg state · legacy v1
zabbix-agentalongside Agent 2, which conflicts on port 10050 · config missingServer=/ServerActive=/Hostname=· missingplugins.dInclude ·CHANGE_MEplaceholder credentials · apt repo added without the agent · and the classic crash loop, a plugin config referencing a loadable plugin whose package is not installed.repairreconciles a broken dpkg state, recreates thetacticalagentunit, starts services that should be running, renames orphaned plugin configs to.disabledso the agent stops crash-looping, adds the missing Include, and clears build leftovers. Anything it cannot fix safely is reported with a next step rather than guessed at.Safety
This script deletes things, so the defaults are deliberately conservative:
reportis the default and is read-only — nothing is removed by accident./var/backupsfirst, and aborts if the backup fails.clean-*action refuses to touch a stack that looks healthy unlessforceis passed. A scheduled run that drifts onto a healthy host must not wipe a working agent.yes. Interactive runs require typingREMOVE.clean-zabbixleaves the apt repo in place (a reinstall needs it);clean-trmmleaves/usr/local/go.Uses
set -uo pipefailwith explicit|| die/|| warnrather than-e, matching the TRMM installer and updater in this repo — on a deliberately broken host, a probe returning non-zero is normal input, not a failure.Test results
Debian 12 containers — 9 scenarios, 29 assertions, all passing:
repairwrites the unit with the correctExecStartrepair/opt/tacticalmeshServer=,ServerActive=,CHANGE_MEplaceholder and missing Include all detected;repairadds the Include and backs the config up firstyestakes a backup then removesThe healthy-stack guard was verified separately (5/5):
yeswill not remove a healthy stack — onlyforcewill, and neither empty noryesgets through.The container has systemd installed but not booted, which also confirmed the script degrades sanely when
systemctlcannot work at all.Not yet exercised on a real host: anything needing a live systemd — the service-restart paths and the
healthystate itself.Progress.mdrecords that.bash -nand shellcheck 0.10.0 clean. README and CLAUDE.md updated.