Say that the rsync count file is a cache the live-PID scan overwrites, so a stale value stops reading as a leak
This commit is contained in:
@@ -1807,6 +1807,11 @@ if [[ -n "${STATE_DIR:-}" ]] && [[ ! -d "$STATE_DIR" ]]; then
|
||||
mkdir -p "$STATE_DIR" 2>/dev/null || true
|
||||
fi
|
||||
|
||||
# A cache, not a ledger. Nothing decrements it — acquire_rsync_lock() recounts live PIDs from the
|
||||
# rsync_*.lock files and overwrites this with the truth before enforcing the limit, so the file
|
||||
# routinely sits at a stale non-zero value with no rsync running. That is expected, not a leak:
|
||||
# killed transfers cannot wedge the limit, because a lock whose PID is dead is not counted.
|
||||
# Read it as "what the last acquire saw", never as "how many are running now".
|
||||
RSYNC_COUNT_FILE="$LOCK_DIR/rsync_active_count"
|
||||
RSYNC_MAX_CONCURRENT=3
|
||||
LOCK_WARN_AGE=300 # seconds — warn if lock older than this (5min default)
|
||||
|
||||
Reference in New Issue
Block a user