ory/hydra · error
failed to set virtual memory limit: %v
Error message
failed to set virtual memory limit: %v
What it means
SetVirtualMemoryLimit wraps syscall.Setrlimit(RLIMIT_AS) failures in this error. It is raised on Unix systems when the process cannot raise/change its address-space rlimit to the requested number of bytes.
Source
Thrown at oryx/jsonnetsecure/limit_unix.go:26
import (
"fmt"
"runtime/debug"
"syscall"
"github.com/pkg/errors"
)
func SetVirtualMemoryLimit(limitBytes uint64) error {
// Tell the Go runtime about the limit.
debug.SetMemoryLimit(int64(limitBytes)) //nolint:gosec // The number is a compile-time constant.
lim := syscall.Rlimit{
Cur: limitBytes,
Max: limitBytes,
}
err := syscall.Setrlimit(syscall.RLIMIT_AS, &lim)
if err != nil {
return errors.WithStack(fmt.Errorf("failed to set virtual memory limit: %v", err))
}
return nil
}
View on GitHub (pinned to 4174065ffb)
Solutions
- Log the wrapped %v to see the errno (EPERM vs EINVAL) and request a limit at or below the current hard limit (getrlimit)
- Run the process with sufficient privileges (CAP_SYS_RESOURCE) or adjust the container/systemd limits
- Use prlimit/ulimit -v at launch time instead of raising it in-process
- Skip the limit call (make it optional) when the platform cannot honor it
Example fix
// before err := jsonnetsecure.SetVirtualMemoryLimit(1 << 40) // 1TB on unprivileged container // after var rl syscall.Rlimit _ = syscall.Getrlimit(syscall.RLIMIT_AS, &rl) err := jsonnetsecure.SetVirtualMemoryLimit(rl.Max) // stay within hard limit
Defensive patterns
Strategy: fallback
Validate before calling
var rl syscall.Rlimit
if err := syscall.Getrlimit(syscall.RLIMIT_AS, &rl); err != nil {
return err
}
if limitBytes > rl.Max {
return fmt.Errorf("requested limit %d exceeds hard rlimit %d", limitBytes, rl.Max)
} Try / catch
if err := jsonnetsecure.SetVirtualMemoryLimit(limitBytes); err != nil {
log.Warn("could not set virtual memory limit, continuing without it", "err", err)
// proceed unbounded rather than aborting startup
} Prevention
- Read the hard rlimit first and never request more than Max
- Account for container/CI sandbox privilege limits (EPERM without CAP_SYS_RESOURCE)
- Treat the memory cap as best-effort: log-and-continue for non-critical paths
- Remember RLIMIT_AS limits virtual memory — set generous values, not RSS targets
When it happens
Trigger: Calling SetVirtualMemoryLimit with a limit higher than the hard rlimit (EPERM), inside a container without CAP_SYS_RESOURCE when raising beyond the hard limit, or on systems where RLIMIT_AS is unavailable/restricted.
Common situations: Docker/Kubernetes containers with low default limits; sandboxed CI runners; running as non-root and asking for more virtual memory than the hard cap; misjudging that RLIMIT_AS counts virtual, not resident, memory.
Related errors
- cookiex: cookie could not be decoded
- cookiex: purpose must be non-empty and must not contain a pi
- cookiex: at least one secret is required
- invalid elliptic curve key size, this algorithm does not sup
- invalid key size for RSA key, 2048 or more is required
AI-assisted analysis of ory/hydra@4174065ffb (2026-09-03).
Data as JSON: /api/errors/dfb7f273c1fa8bc8.
Report an issue: GitHub.