podman: container create failed: container_linux.go:336: starting container process caused "process_linux.go:293: applying cgroup configuration for process caused open /sys/fs/cgroup/cpuset/machine.slice/cpuset.cpus: no such file or directory"
Is this a BUG REPORT or FEATURE REQUEST?:
[//]: # Uncomment only one, leave it on its own line:
kind bug
[//]: # kind feature
Description
From time to time, we are hit by a failure while starting a container:
2018-11-21 01:23:16 INFO | "2018-11-21 01:20:36,157 ERROR: 5978 -- container create failed: container_linux.go:336: starting container process caused \"process_linux.go:293: applying cgroup configuration for process caused \\\"open /sys/fs/cgroup/cpuset/machine.slice/cpuset.cpus: no such file or directory\\\"\""
2018-11-21 01:23:16 INFO | ": internal libpod error", 2018-11-21 01:23:16 INFO | "",
We don’t have much more logs unfortunately. The action is “podman run”, just after we have pulled the image. The failure hit randomly any container, so it’s not an issue related to the image nor way we run it.
Steps to reproduce the issue:
-
It’s a random failure, we didn’t find any trigger for that 😦.
Describe the results you received: Sometimes `podman run’ fails.
Describe the results you expected: It should have a consistent behaviour and run the container without random failure
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version
:
Version: 0.11.1.1
Go Version: go1.10.2
OS/Arch: linux/amd64
Output of podman info
:
host:
BuildahVersion: 1.5-dev
Conmon:
package: podman-0.11.1.1-3.git594495d.el7.x86_64
path: /usr/libexec/podman/conmon
version: 'conmon version 1.12.0-dev, commit: ccde1bf8e093607ecf92b404368033f645cad755-dirty'
Distribution:
distribution: '"centos"'
version: "7"
MemFree: 874045440
MemTotal: 8365137920
OCIRuntime:
package: runc-1.0.0-55.dev.git2abd837.el7.x86_64
path: /usr/bin/runc
version: 'runc version spec: 1.0.0'
SwapFree: 8557686784
SwapTotal: 8588881920
arch: amd64
cpus: 8
hostname: undercloud.localdomain
kernel: 3.10.0-862.14.4.el7.x86_64
os: linux
rootless: false
uptime: 59m 56.33s
insecure registries:
registries:
- 192.168.24.1:8787
- 192.168.24.3:8787
registries:
registries:
- docker.io
- registry.fedoraproject.org
- quay.io
- registry.access.redhat.com
- registry.centos.org
store:
ContainerStore:
number: 1
GraphDriverName: overlay
GraphOptions:
- overlay.override_kernel_check=true
GraphRoot: /var/lib/containers/storage
GraphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "true"
Supports d_type: "true"
ImageStore:
number: 19
RunRoot: /var/run/containers/storage
Additional environment details (AWS, VirtualBox, physical, etc.):
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 15 (12 by maintainers)
Alright, so this is definitely the systemd driver then - good to know I’m looking in the right place