exec2 driver: GOMAXPROCS auto-detection fails in Go 1.25 due to cgroup namespacing

[aditi502]

When using the exec2 driver with Go 1.25+ services, the Go runtime fails to auto-detect cgroup CPU quotas, defaulting instead to the total host core count. This occurs even when /sys/fs/cgroup and /proc are unveiled.

Observed Behavior
In Go 1.25, the runtime natively attempts to discover CPU limits via cgroup v2. However, inside an exec2 task, the process is placed in a new cgroup namespace.

/proc/self/cgroup reports the process is at the cgroup root (0::/).

Go runtime is not picking up the allocation's actual slice limit (nomad.slice/alloc-.../cpu.max), it defaults to the number of host cores causing overthreading.

Nomad v1.10.4
Go 1.25

[schmichael]

Thanks for the report @aditi502. I can confirm Go's runtime is unable to properly detect GOMAXPROCS when cpu is specified.

However, if you use cores = <N> instead, Go's runtime appears to detect that setting properly in both NumCPU and GOMAXPROCS.

This is still a bug, but hopefully that's a useful workaround until the bug is fixed.

[aditi502]

I have tried setting cores = N, im still seeing the gomaxprocs defaulting to the number of host cores

[tgross]

Internal ref https://hashicorp.atlassian.net/browse/NMD-1318