Gmer4Lfe
2a062e5140
Every orchestrator invoked its children differently — four near-duplicate run_job() copies, a differently-shaped run_watchdog(), or plain inline bash calls, each with its own take on path resolution, pass/fail naming, and dry-run threading. Extracted one shared run_orch_child() into common.sh so there's a single place to fix or extend this behavior going forward. Along the way: watchdog_orchestrator.sh and monthly_maintenance.sh were checking $VERBOSE, a variable nothing in the codebase ever assigns, so --log silently did nothing beyond basic logging on those two. Fixed to $ENABLE_LOGGING. watchdog_orchestrator.sh and array_started.sh had no trailing exit, so their exit codes reflected whatever the last command happened to return rather than actual success/failure. transcode_management.sh had no failure notification and no summary at all. Also made transcode_management.sh's two-script pipeline config-driven (TRANSCODE_MANAGEMENT_SCRIPTS in master.conf) instead of hardcoded, for room to extend it later without editing the orchestrator itself.
Configurations/
Runtime home for the live conf files. These are gitignored — never committed.
| File | Source |
|---|---|
master.conf |
Seeded from Deployment/master.conf.template on first install |
host1.conf |
Seeded from Deployment/host.conf.template on first install |
host2.conf |
Seeded from Deployment/host.conf.template on first install |
Templates and tooling live in Deployment/:
Deployment/host.conf.template— canonical template for new host confsDeployment/master.conf.template— canonical template for master.confDeployment/conf_upgrade.sh— merges schema changes into existing confsDeployment/conf_populate.sh— auto-detects and fills arr keys on first run