From d99b560cec749a6ebe5686facff346bef57f9975 Mon Sep 17 00:00:00 2001 From: Scooby Husky Date: Thu, 20 Aug 2026 23:39:49 -0500 Subject: [PATCH] Loosen VPS GitLab sidekiq liveness probe further (~17min grace) 3 consecutive attempts with the first loosening (~8min grace) all made genuine progress (booted, started listening on queues) but never got to open the health-check port before being killed - box's sustained background load (gitea, restic, barman, k3s - unrelated to GitLab) is apparently enough to starve that specific thread. More patience, not a different fix. Co-Authored-By: Claude Sonnet 5 --- infrastructure/vps-standby/gitlab/values.yaml | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/infrastructure/vps-standby/gitlab/values.yaml b/infrastructure/vps-standby/gitlab/values.yaml index 7b0f060..7673693 100644 --- a/infrastructure/vps-standby/gitlab/values.yaml +++ b/infrastructure/vps-standby/gitlab/values.yaml @@ -237,12 +237,22 @@ gitlab: # getting SIGTERM'd mid-`require` by the liveness probe on this # CPU-contended box, every ~90-150s, resetting to zero each time # and never actually finishing. + # Loosened further 2026-08-21: even with the first pass above, 3 + # consecutive attempts all reached "Booting Sidekiq" (the real + # engine actually starts, confirmed via "Listening on queues" in + # logs) but never opened the health-check port (3808) within the + # ~8min grace window - the box's ambient background load (gitea, + # restic backup, barman, k3s itself - all unrelated to GitLab, load + # average sustained 35-55 on 6 cores) is apparently severe enough to + # starve that specific thread's CPU scheduling even after the main + # process is otherwise up. Genuine forward progress each time, not + # a hard hang, so more patience rather than a code fix. livenessProbe: - initialDelaySeconds: 60 + initialDelaySeconds: 120 periodSeconds: 30 timeoutSeconds: 30 successThreshold: 1 - failureThreshold: 15 + failureThreshold: 30 resources: requests: cpu: 25m