fix(maxprocs): treat ConfigureMaxProcs error as non-fatal#7655
fix(maxprocs): treat ConfigureMaxProcs error as non-fatal#7655JorTurFer merged 1 commit intokedacore:mainfrom
Conversation
|
Thank you for your contribution! 🙏 Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected. While you are waiting, make sure to:
Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient. Learn more about our contribution guide. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
ManvithaP-hub
force-pushed
the
fix/maxprocs-non-fatal-7653
branch
from
00b6b3f to
d2e83e9
Compare
|
@ManvithaP-hub , it looks like there are three checks queued for more than five days. |
When KEDA runs in environments where /sys/fs/cgroup/cpu.max is not readable (e.g. EKS auto-mode, restricted SecurityContexts), maxprocs.Set() returns a permission error and KEDA crashes on startup. The Go runtime handles GOMAXPROCS sensibly without explicit configuration, so this error should not be fatal. Log it as a warning and continue startup. Fixes kedacore#7653 Signed-off-by: ManvithaP-hub <62259625+ManvithaP-hub@users.noreply.github.com>
ManvithaP-hub
force-pushed
the
fix/maxprocs-non-fatal-7653
branch
from
d2e83e9 to
5d200bf
Compare
@colineinfalt : Thanks for looking into this. It looks like the ARM smoke tests have been running for 11+ hours and S390x/e2e tests are still queued. This seems like a runner availability issue rather than anything wrong with the PR. Is there a way to re-trigger the stuck checks? ARM smoke tests --> running (started 11h ago —> this is the slow one) |
|
These are the E2E tests. They can only be started by Reviewers or Maintainers. We do this once we have reviewed a PR. |
|
/run-e2e internal |
|
Thanks a lot for the fix! |
) When KEDA runs in environments where /sys/fs/cgroup/cpu.max is not readable (e.g. EKS auto-mode, restricted SecurityContexts), maxprocs.Set() returns a permission error and KEDA crashes on startup. The Go runtime handles GOMAXPROCS sensibly without explicit configuration, so this error should not be fatal. Log it as a warning and continue startup. Fixes kedacore#7653 Signed-off-by: ManvithaP-hub <62259625+ManvithaP-hub@users.noreply.github.com>
) When KEDA runs in environments where /sys/fs/cgroup/cpu.max is not readable (e.g. EKS auto-mode, restricted SecurityContexts), maxprocs.Set() returns a permission error and KEDA crashes on startup. The Go runtime handles GOMAXPROCS sensibly without explicit configuration, so this error should not be fatal. Log it as a warning and continue startup. Fixes kedacore#7653 Signed-off-by: ManvithaP-hub <62259625+ManvithaP-hub@users.noreply.github.com> Signed-off-by: Abhishek Kumar Kushwaha <abhithegabbar@gmail.com>
4 participants
Summary
KEDA pods crash on startup with
failed to set max procs: open /sys/fs/cgroup/cpu.max: permission deniedin environments where the operator cannot read cgroup files (e.g. EKS auto-mode, restricted SecurityContexts).Root Cause
maxprocs.Set()fromgo.uber.org/automaxprocsreturns an error when it can't read/sys/fs/cgroup/cpu.max, and all three KEDA entry points (operator, webhooks, adapter) treat this as fatal.Fix
Log the error as a warning and continue startup. The Go runtime will use a sensible default
GOMAXPROCSvalue, so this is not actually a fatal condition.Applied the same fix to all three entry points:
cmd/operator/main.gocmd/webhooks/main.gocmd/adapter/main.goValidation
go build ./cmd/operator/ ./cmd/webhooks/ ./cmd/adapter/succeedsFixes #7653