MTGuardianX v5

Profile-scoped Bash supervisor for MoonTrader MTCore.

MTGuardianX starts, monitors, classifies, and restarts exactly one MTCore profile. It is a consolidated final version built from the original Greendq/MTGuardian, the local V3/V4 branches, and the external audit comments.

This MT_Agent copy adds non-invasive fleet observability: status JSON, event JSONL, crash snapshots, and sidecar-readable reports. These writes are best-effort and never gate the original restart path.

• MTGuardianX - production script.
• test_mtguardianx.sh - fake-MTCore functional harness.
• example.conf - editable config template.
• mtguardianx@.service.example - optional systemd service template.
• SUMMARY.md - implementation and handoff summary.

chmod +x MTGuardianX test_mtguardianx.sh

# Create a config interactively.
./MTGuardianX --configure

# Or adapt example.conf, then run:
./MTGuardianX --config example.conf

# Inspect local guardian state.
./MTGuardianX --config example.conf --status
./MTGuardianX --config example.conf --dump-report

To stop the guardian without killing MTCore:

kill -TERM <mtguardianx-pid>

The config is intentionally Bash-sourceable because the original spec requires that. V5 mitigates the risk by refusing group/world-writable configs on POSIX systems and by generating config values with Bash-safe quoting.

Use array form for MTCore arguments:

MT_CORE_ARGS=(--no-update --data-dir '/path with spaces')

Legacy string form still works for simple flags:

MT_CORE_ARGS='--no-update'

If TG_NOTIFICATIONS=1, keep the config mode at 600 because it contains the Telegram token.

Real fleet profile names such as Tour_IRN_003 are accepted. The profile regex allows letters, digits, underscore, dot, and hyphen.

Observability defaults:

MTGX_STATE_ROOT=/run/mtguardianx
MTGX_LOG_ROOT=/var/log/mtguardianx
MTGX_REPORT_LOG_LINES=1000

This produces:

• /run/mtguardianx/<profile>/status.json
• /var/log/mtguardianx/<profile>.events.jsonl
• /var/log/mtguardianx/<profile>.last-crash.log

Local restart requests are disabled by default. If an operator intentionally sets MTGX_ALLOW_REQUEST_RESTART=1, --request-restart <reason> writes a request file that the running guardian consumes and turns into a TERM/restart cycle for the supervised core.

bash -n ./MTGuardianX
bash -n ./test_mtguardianx.sh
bash ./test_mtguardianx.sh

Expected result:

ALL TESTS PASSED

• SIGSEGV-specific !Alarm detection is only possible for MTCore processes launched by this guardian. Externally attached MTCore processes cannot expose their wait status to a non-parent process, so they are classified by stale .cscdat.
• The real Telegram API is not called by the test harness. Do one manual smoke test with a throwaway bot/chat before relying on Telegram in production.
• rc.local is supported because the spec asks for it, but systemd deployments should prefer adapting mtguardianx@.service.example.