What causes "failed to set cpuset: %w" in hashicorp/nomad?

Verify cpuset cgroup v1 controller is mounted and writable (check /sys/fs/cgroup/cpuset) on the host

failed to set cpuset: %w

Error message

failed to set cpuset: %w

What it means

This error wraps a failure from cpusetCG1, which writes the CPU set (allowed CPU cores) to the cpuset cgroup v1 controller for a Nomad task. Nomad sets cpuset manually because libcontainer will not write it for Nomad's special cpuset cgroup. The underlying error typically indicates the cpuset cgroup file could not be opened or written.

Source

Thrown at drivers/shared/executor/executor_linux_cgo.go:834

}

func (l *LibcontainerExecutor) configureCG1(cfg *runc.Config, command *ExecCommand, cgroup string) error {

	cpuShares := l.clampCpuShares(command.Resources.LinuxResources.CPUShares)
	cpusetPath := command.Resources.LinuxResources.CpusetCgroupPath
	cpuCores := command.Resources.LinuxResources.CpusetCpus

	// Set the v1 parent relative path (i.e. /nomad/<scope>) for the NON-cpuset cgroups
	scope := filepath.Base(cgroup)
	cfg.Cgroups.Path = filepath.Join("/", cgroupslib.NomadCgroupParent, scope)

	// set cpu resources
	cfg.Cgroups.Resources.CpuShares = uint64(cpuShares)

	// we need to manually set the cpuset, because libcontainer will not set
	// it for our special cpuset cgroup
	if err := l.cpusetCG1(cpusetPath, cpuCores); err != nil {
		return fmt.Errorf("failed to set cpuset: %w", err)
	}

	// tell libcontainer to write the pid to our special cpuset cgroup
	l.configureCgroupHook(cfg, command)

	return nil
}

func (l *LibcontainerExecutor) cpusetCG1(cpusetCgroupPath, cores string) error {
	if cores == "" {
		return nil
	}
	ed := cgroupslib.OpenPath(cpusetCgroupPath)
	return ed.Write("cpuset.cpus", cores)
}

func (l *LibcontainerExecutor) configureCG2(cfg *runc.Config, command *ExecCommand, cg string) error {
	cpuShares := l.clampCpuShares(command.Resources.LinuxResources.CPUShares)

View on GitHub (pinned to 482b49bf1a)

Solutions

Verify cpuset cgroup v1 controller is mounted and writable (check /sys/fs/cgroup/cpuset) on the host
Run the Nomad client with the required cgroup privileges (privileged container, cgroup mounts delegated)
Confirm the task's cpu.cores value produces a valid CPU mask that exists on the host
Consider cgroups v2 or a plugin driver if the host does not use cgroup v1

Example fix

// before (client in Docker without cgroup access)
docker run hashicorp/nomad agent -dev
// after
docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup hashicorp/nomad agent -dev

Defensive patterns

Strategy: validation

Validate before calling

// before launching tasks on a client node:
if _, err := os.Stat("/sys/fs/cgroup/cpuset"); err != nil {
    // node lacks cpuset cgroup v1; don't schedule cgroup tasks here
}

Try / catch

if err := executor.Launch(lctx, cmd); err != nil {
    if strings.Contains(err.Error(), "failed to set cpuset") {
        // mark node cgroup-v1 incompatible, reschedule elsewhere
    }
}

Prevention

Run Nomad clients with cgroup v1 controllers mounted and writable
In containerized clients use --privileged and mount /sys/fs/cgroup
Pin tasks to nodes with verified cgroup capabilities via constraints

When it happens

Trigger: configureCG1 runs during task launch when configureCgroups initializes cgroup v1 resources; it triggers when the cpuset.cpus file for the task's cgroup cannot be written, e.g. missing cgroup filesystem, no writable cpuset controller, or invalid CPU mask.

Common situations: Host without cpuset cgroup v1 controller mounted or delegated (common in containers/CI without privileged cgroup access); cgroup v2-only hosts; selinux/read-only /sys/fs/cgroup; running Nomad client in Docker without cgroup namespace privileges.

Related errors

AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/700abf347aba1bfe. Report an issue: GitHub.