Fix rsync.sh global lock bug and add a max-runtime cap

acquire_lock (no args) ran before profile inference, so every rsync.sh invocation — regardless of share — fought over one generic, unparameterized lock. The per-profile acquire_rsync_lock() further down (with RSYNC_MAX_CONCURRENT) never got a chance to matter: a single slow transfer (e.g. Movies during the HOST2 rebuild) monopolized the lock and starved every other profile, including Critical-Data's 30-minute sync, for days. Removed the generic acquire_lock call; acquire_rsync_lock "$PROFILE_NAME" already provides correct per-profile locking on its own. Also added RSYNC_MAX_RUNTIME_HOURS (default 23): any single transfer attempt exceeding it is terminated via timeout, logged as paused rather than failed, and resumes from where it left off next scheduled run (safe because --partial is already in DEFAULT_RSYNC_OPTS). Bounds the worst case for one huge/stuck share instead of letting it hold its lock indefinitely.
2026-07-11 17:10:37 -04:00
parent 35d7909828
commit 85c3aef1b0
2 changed files with 30 additions and 7 deletions
@@ -531,6 +531,7 @@
    BW_LIMIT=12500                  # KB/s — 12500 ≈ 100Mbit
    RETRY_COUNT=3                   # retry attempts before giving up
    SLEEP=300                       # seconds between retry attempts
+    RSYNC_MAX_RUNTIME_HOURS=23      # cap per transfer attempt — pauses and resumes next scheduled run
    CRITICAL_CONTAINER_NAMES=()     # containers stopped on REMOTE before rsync — profiles override
    DELAYED_CONTAINERS=()           # containers needing delay before starting — profiles override
    CONTAINER_DELAY=5               # seconds before starting delayed containers