Widen unraid-api key lookup timeout to stop false "renewed" alarms
Measured live: the apikey --name lookup takes 2.2-2.7s baseline with the system idle, against a 5s timeout that left almost no margin. Load spikes (confirmed correlated with resource_watchdog pressure events in the same log window) pushed it over 5s, and the script couldn't distinguish "timed out" from "genuinely missing" — it fell through to the create path and logged a false renewal every time, even though the on-disk key file's timestamp never actually changed. Bumped to 15s for real headroom.
This commit is contained in:
@@ -86,8 +86,16 @@ fi
|
||||
# Check if key already exists in the unraid-api registry before creating.
|
||||
# --overwrite generates a new key value every time, invalidating the old one.
|
||||
# Only renew if the registry has lost it.
|
||||
#
|
||||
# Timeout was 5s — measured live 2026-07-19 at 2.2-2.7s baseline latency for this
|
||||
# exact command with the system idle, leaving almost no margin. Any load spike
|
||||
# (confirmed correlated with resource_watchdog "pressure escalating" events in the
|
||||
# same log) pushed it past 5s, killing the lookup — the script then couldn't tell
|
||||
# "timed out" from "genuinely not in the registry" and fell through to the create
|
||||
# path, logging a false "API key renewed (registry had lost it)" even though the
|
||||
# on-disk key file's timestamp never actually changed. 15s gives real headroom.
|
||||
log "Checking unraid-api registry for $KEY_NAME..."
|
||||
EXISTING=$(timeout 5 /usr/local/sbin/unraid-api apikey --name "$KEY_NAME" --json </dev/null 2>/dev/null)
|
||||
EXISTING=$(timeout 15 /usr/local/sbin/unraid-api apikey --name "$KEY_NAME" --json </dev/null 2>/dev/null)
|
||||
KEY=$(echo "$EXISTING" | jq -r '.key // empty' 2>/dev/null)
|
||||
|
||||
if [[ -n "$KEY" ]]; then
|
||||
|
||||
Reference in New Issue
Block a user