Ubuntu 24 and ubuntu 22(rare) problem with unknow capability CAP_PERFMON #724
-
If i run the container on the latest docker on latest ubuntu 24.04 the rabbitmq container can not be started. Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: container_linux.go:349: starting container process caused "unknown capability "CAP_PERFMON"": unknown I tried alpine and ubuntu images of rabbitmq. This happens on all ubuntu 24 - and on some 22 as well. I have several ubuntu 22 where the container is working like a charm. If i do a "new" install for ubuntu 22 it usually works. I use docker 27.2.1 I also tried CapAdd but there was no change. The container is up in promiscous mode so it should not be a permission problem The image is created but can not be started any ideas? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
This feels like a Ubuntu or docker issue, not one that is specific to this image (search). When I have time this week, I will double-check using my Ubuntu and Arch Linux envs. @tianon, no rush, but anything to add? |
Beta Was this translation helpful? Give feedback.
-
Well its definetly connected to your image all other docker images and there are countless work like a charm. Your image works on almost all of the current ubunut (i got like 20 running, 2 have problems on obuntu 22) the new ones break all the times. I did a week of reserch could find people who have this problem with docker and even some with rabbit - no solution so far. |
Beta Was this translation helpful? Give feedback.
-
A very quick search suggests it is a known phenomenon with certain container engines and it affects "privileged containers" ("privileged pods") only, so the difference with "other images that work like a charm" can be that they do not run as privileged. It even affects parts of Kubernetes. cri-o/cri-o#4478, kubernetes-sigs/kind#2058, opencontainers/runtime-spec#1094, k3s-io/k3s#3296 |
Beta Was this translation helpful? Give feedback.
A very quick search suggests it is a known phenomenon with certain container engines and it affects "privileged containers" ("privileged pods") only, so the difference with "other images that work like a charm" can be that they do not run as privileged.
It even affects parts of Kubernetes.
cri-o/cri-o#4478, kubernetes-sigs/kind#2058, opencontainers/runtime-spec#1094, k3s-io/k3s#3296