-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raspbian: Error response from daemon: unable to find "net_prio" in controller set: unknown #545
Comments
I have the same issue on Kali |
Hello, Could be related to systemd. There is an similary issue here: #552 . |
@Pea13 its related to systemd. Please downgrade systemd to resolve that problem for now. The issue is present on 240 version and above. Older versions are fully functional. |
It seems complicated. I only have the latest version available:
Maybe i can do some tests with this new version ? |
To fix it on my system I just needed to rebuild my kernel with CONFIG_CGROUP_NET_PRIO enabled |
|
That's really annoying.. The only solutions are :
|
@Pea13 I fixed it just by downgrading systemd. I watching multiple similar issues so I will wait until the issues with systemd will be fixed. :) |
Yes i know, but for raspbian stretch, older packages are no longer available :( |
Did anyone report this to systemd? |
@lategoodbye nope.. because they know about it. just read the changelog. |
I read the NEWS file for version 240 and didn't find anything about CONFIG_CGROUP_NET_PRIO. Could you please point me to the relevant part? |
@lategoodbye in-case you didn't find it, @TheAifam5 posted which parts of systemd 240 changelog seem related on a linked github issue: Seems like systemd changed the way they expose cgroups and it's fooling Docker into thinking controllers are available when they're not, or vice versa? Adding the cgroup to the kernel config papers over the issue by implementing the cgroup controller, but on some kernels like CK / MuQSS, some controllers are unavailable entirely (cpuacct), and worked fine up until systemd 240. |
I agree. On raspbian's kernel, the option |
@damentz Thanks. I read this section but this doesn't clearly explain why CONFIG_CGROUP_NET_PRIO must be enabled. I think this issue should be solved in userspace. Sorry, but i'm pretty annoyed that systemd has such a dependency from specific kernel config options. Did anyone tried to add |
I just tried it now and got the same result as I did without it for a MuQSS based kernel. I can't confirm the same result with Raspbian, but I suspect it will be the same. |
Thanks for testing this. |
Are (or were) you using |
FYI when Fedora 30 is released, it may likely have systemd 240. This may have an effect on Fedora x86_64 if the issue is found to be caused by systemd 240 behaviour. |
No. No |
Looking at where the actual error is coming from, it seems to be from comparing the list of cgroups with the mounts. Can you post |
And for reference since I'm coming from a linked github issue (#552), my particular message when running a container is |
On Raspbian buster
|
any fix for this? |
same question. |
is this MR that was just merged going to fix this? |
looks like it will be fixed in next release of containerd |
Relevant changes: - containerd/containerd#51 Fix empty device type - containerd/containerd#52 Remove call to unitName - Calling unitName incorrectly appends -slice onto the end of the slice cgroup we are looking for - addresses containerd/containerd#47 cgroups: cgroup deleted - containerd/containerd#53 systemd-239+ no longer allows delegate slice - containerd/containerd#54 Bugfix: can't write to cpuset cgroup - containerd/containerd#63 Makes Load function more lenient on subsystems' checking - addresses containerd/containerd#58 Very strict checking of subsystems' existence while loading cgroup - containerd/containerd#67 Add functionality for retrieving all tasks of a cgroup - containerd/containerd#68 Fix net_prio typo - containerd/containerd#69 Blkio weight/leafWeight pointer value - containerd/containerd#77 Check for non-active/supported cgroups - addresses containerd/containerd#76 unable to find * in controller set: unknown - addresses docker/for-linux#545 Raspbian: Error response from daemon: unable to find "net_prio" in controller set: unknown - addresses docker/for-linux#552 Error response from daemon: unable to find "cpuacct" in controller set: unknown - addresses docker/for-linux#545 Raspbian: Error response from daemon: unable to find "net_prio" in controller set: unknown Signed-off-by: Sebastiaan van Stijn <[email protected]>
Change-type: patch Connects-to: docker/for-linux#545 Signed-off-by: Robert Günzler <[email protected]>
Fixes issues with systemd versoin >=420 and non-existent cgroups. Change-type: patch Connects-to: containerd/cgroups#76 Connects-to: docker/for-linux#545 Signed-off-by: Robert Günzler <[email protected]>
Fixes issues with systemd version >=420 and non-existent cgroups. Change-type: patch Connects-to: containerd/cgroups#76 Connects-to: docker/for-linux#545 Signed-off-by: Robert Günzler <[email protected]>
This doesn't seem fixed in current raspbian. On a raspberry pi 3, I installed raspbian buster lite (from
I have:
And:
I don't understand where to look for "Containerd 1.2.5-1", which is quoted above as working, but my overall docker version is later than the one quoted above. Is this a regression, or some problem with raspbian versioning? If so, how do I identify it? |
It seems you can check with kubectl # kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
minisub1 Ready master 99m v1.14.3-k3s.1 192.168.2.34 <none> Raspbian GNU/Linux 10 (buster) 4.19.50-v7l+ containerd://1.2.5+unknown
minisub2 Ready worker 6m41s v1.14.3-k3s.1 192.168.2.36 <none> Raspbian GNU/Linux 10 (buster) 4.19.50-v7l+ containerd://1.2.5+unknown I have 1.2.5+unknown - dunno what "unknown" part is, but in any case we still get the same error as you. The versions of everything else appear to be correct |
@sbrudenell Assuming the hash in your (and my) Although given some other reports of the same error, the real problem is I think that docker haven't done an official buster release for raspbian yet - we might have to wait for that and change over to |
Could you reopen the issue? As @sbrudenell says, this doesn't seem fixed in current raspbian. |
the issue is still there on rasbian buster |
agree with @Azim254 . the issue is still there on raspbian buster |
Just fresh installed buster on a pi 3B+ and same issue, seems its indeed still there |
Hi root@raspberrypi:/opt/dockerprojets/homeassistant# docker info | grep containerd |
Hi jma@raspberrypi:~ $ sudo docker run hello-world Linux raspberrypi 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l GNU/Linux |
same problem with raspbian lite and pi3B+ |
root@raspberrypi:/var/log# sudo docker run hello-world |
Jul 17 19:03:54 raspberrypi dockerd[1763]: time="2019-07-17T19:03:54.482258725+01:00" level=error msg="8f6339687216a9d27258e171646bfc7740721559af3f4a7eca3587a2e8ee4d8a cleanup: failed to delete container from containerd: no such container" |
This github issue entry is closed. I already opened another issue entry |
containerd.io packages have been uploaded to the nightly channel. You can install the latest nightly release using: curl -fsSL get.docker.com | CHANNEL=nightly sh |
@jugou28 This works for me too! |
@jugou28 works for me too. |
It works for me too, rpi buster |
Expected behavior
Create and run containers.
Actual behavior
Steps to reproduce the behavior
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.)
I use Raspbian buster with the latest kernel (branch next) :
Linux docker02 4.19.13-v7+ #1186 SMP Tue Jan 1 11:32:58 GMT 2019 armv7l GNU/Linux
.Everything was working fine but since the last upgrade (of Raspbian), it seems to be broken.
Do you have any ideas or tests i can do ?
Regards.
Thanks,
The text was updated successfully, but these errors were encountered: