cgroups: cannot found cgroup mount destination: unknown

xgenvn commented 6 years ago

[x] This is a bug report
[ ] This is a feature request
[x] I searched existing issues before opening this one

Expected behavior

docker run hello-world

should run normally.

Actual behavior

docker run hello-world
docker: Error response from daemon: cgroups: cannot found cgroup mount destination: unknown.

Steps to reproduce the behavior

Install latest stable or edge builds (17.12 or 18.01), using: https://docs.docker.com/install/linux/docker-ce/ubuntu/

Output of docker version:

Client:                                    
 Version:       18.01.0-ce                 
 API version:   1.35                       
 Go version:    go1.9.2                    
 Git commit:    03596f5                    
 Built: Wed Jan 10 20:11:05 2018           
 OS/Arch:       linux/amd64                
 Experimental:  false                      
 Orchestrator:  swarm                      

Server:                                    
 Engine:                                   
  Version:      18.01.0-ce                 
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2                    
  Git commit:   03596f5                    
  Built:        Wed Jan 10 20:09:37 2018   
  OS/Arch:      linux/amd64                
  Experimental: false

Output of docker info:

Containers: 16                                                                    
 Running: 0                                                                       
 Paused: 0                                                                        
 Stopped: 16                                                                      
Images: 1                                                                         
Server Version: 18.01.0-ce                                                        
Storage Driver: overlay2                                                          
 Backing Filesystem: extfs                                                        
 Supports d_type: true                                                            
 Native Overlay Diff: true                                                        
Logging Driver: json-file                                                         
Cgroup Driver: cgroupfs                                                           
Plugins:                                                                          
 Volume: local                                                                    
 Network: bridge host macvlan null overlay                                        
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog    
Swarm: inactive                                                                   
Runtimes: runc                                                                    
Default Runtime: runc                                                             
Init Binary: docker-init                                                          
containerd version: 89623f28b87a6004d4b785663257362d1658a729                      
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f                            
init version: 949e6fa                                                             
Security Options:                                                                 
 seccomp                                                                          
  Profile: default                                                                
Kernel Version: 4.4.0                                                             
Operating System: Ubuntu 16.04.3 LTS                                              
OSType: linux                                                                     
Architecture: x86_64                                                              
CPUs: 1                                                                           
Total Memory: 512MiB                                                              
Name: SRV_01                                                                      
ID: BBRL:P36V:7QOO:IRBR:X2TC:UC47:4L7N:IIIQ:OLSL:KWS2:OVAZ:TKKF                   
Docker Root Dir: /var/lib/docker                                                  
Debug Mode (client): false                                                        
Debug Mode (server): false                                                        
Registry: https://index.docker.io/v1/                                             
Labels:                                                                           
Experimental: false                                                               
Insecure Registries:                                                              
 127.0.0.0/8                                                                      
Live Restore Enabled: false                                                       

WARNING: No cpuset support                                                        
WARNING: bridge-nf-call-iptables is disabled                                      
WARNING: bridge-nf-call-ip6tables is disabled

Additional environment details (AWS, VirtualBox, physical, etc.)

> uname -a

Linux DAAA_S1 4.4.0 #1 SMP Fri Jan 5 21:20:16 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

> ls /sys/fs/cgroup/
beancounter  cpu          cpuacct  freezer  memory   net_cls,net_prio  perf_event  systemd
blkio        cpu,cpuacct  devices  hugetlb  net_cls  net_prio          pids        ve

AppArmor is also deactivated. Running under root terminal/normal terminal returns same issue. Docker pull is working. Confirmed working under 17.09.1~ce-0~ubuntu

aleade commented 4 years ago

Hi all, I am having the same issue, but even If I try the temporary solution above I get:

mount: cgroup is already mounted or /sys/fs/cgroup/systemd busy cgroup is already mounted on /sys/fs/cgroup/systemd cgroup is already mounted on /sys/fs/cgroup/cpuset cgroup is already mounted on /sys/fs/cgroup/blkio cgroup is already mounted on /sys/fs/cgroup/memory cgroup is already mounted on /sys/fs/cgroup/devices cgroup is already mounted on /sys/fs/cgroup/freezer cgroup is already mounted on /sys/fs/cgroup/perf_event cgroup is already mounted on /sys/fs/cgroup/hugetlb cgroup is already mounted on /sys/fs/cgroup/pids

dioni21 commented 4 years ago

sudo mkdir /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

but of cause the mount is gone after restart

This worked for me! Thanks!

valorad commented 4 years ago

For Fedora 31, this worked for me

Open /etc/default/grub as admin
Append value of GRUB_CMDLINE_LINUX with systemd.unified_cgroup_hierarchy=0
- e.g. GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

Execute one of the following commands:

# if using UEFI
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
# or if using BIOS
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Restart your computer

(Source: Fedora 31 and Container (Docker-ce, Moby-engine) Start Systemd Problem )

gutudumitru commented 4 years ago

For Fedora 31, this worked for me

Open /etc/default/grub as admin

Append value of GRUB_CMDLINE_LINUX with systemd.unified_cgroup_hierarchy=0

e.g. GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

Execute one of the following commands:
    # if using UEFI
    sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
    # or if using BIOS
    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
(Source: Fedora 31 and Container (Docker-ce, Moby-engine) Start Systemd Problem )

Works for me for Fedora 31 with Docker 19.03.8 Thank you!

h908714124 commented 4 years ago

For Fedora 31, this worked for me

1. Open /etc/default/grub as admin

2. Append value of GRUB_CMDLINE_LINUX with systemd.unified_cgroup_hierarchy=0

   * e.g. `GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"`

3. Execute one of the following commands:

    # if using UEFI
    sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
    # or if using BIOS
    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

1. Restart your computer

(Source: Fedora 31 and Container (Docker-ce, Moby-engine) Start Systemd Problem )

My dude, there is already a line GRUB_CMDLINE_LINUX="resume=UUID=102bdb11-5513-4214-89d8-4f497fe6027b rhgb quiet" in that grub file. Do I need to merge these somehow. Also the file has a readonly flag, is this safe?

openterprise commented 4 years ago

Do not create new line, you need to change existing line to look like this: GRUB_CMDLINE_LINUX="resume=UUID=102bdb11-5513-4214-89d8-4f497fe6027b systemd.unified_cgroup_hierarchy=0 rhgb quiet"

It is working for both Fedora 31 and Fedora 32 Beta.

Next thing is to rebuild GRUB2 config file. For BIOS computers: sudo grub2-mkconfig -o /boot/grub2/grub.cfg For UEFI computers: sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

h908714124 commented 4 years ago

@openterprise Thanks, boss!

BartSchipperijn commented 4 years ago

@openterprise I had the same problem and your comment solved it. Thanks!

reetp commented 4 years ago

It is working for both Fedora 31 and Fedora 32 Beta.

That presumably doesn't work if you run non systemD.

Your hack just worked fine for me. I'm running on a Devuan, without systemd...

Not now - just tried jitsi-meet and it failed.

obayesshelton commented 4 years ago

Hi all,

I just had a very similar issue. I was on Azure, encrypted an OS disk and could see the disk but docker-compose would not run as I was mounting the host to the guest. I restarted the VM and it re-mounted the disk and it works again. I don't want to say it but turning it on and off might work in some cases. Always worth a try

vsayanam commented 4 years ago

Thank you, d-a-v, Your suggestion to reinstall: 'sudo apt-get install docker-ce=17.09.1~ce-0~debian' worked in my case. I use devuan ascii in one desktop. With great difficulty, I installed docker and through it jellyfin. It was working all right for sometime. When I switched on this PC after some gap, I ran into error quoted above. I was about to start all over again but your suggestion helped me to save time and efforts. Thanks again!

gilvangobbato commented 4 years ago

Hi, Solution from this post https://forum.linuxconfig.org/t/how-to-install-docker-on-fedora-31-linuxconfig-org/3605/3 worked for me on Fedora 31 with Docker 19.03.5 and kernel 5.3.11-300.fc31.x86_64:
$ sudo dnf install -y grubby
$ sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
$ sudo reboot

nice.... very nice... Thanks

nived15 commented 4 years ago

I ran into similar issue found a temp fix on another place. Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

For people using fedora 31: Fedora 31 uses cgroupv2 which is not supported by docker yet. So here is what you can do (any one):

Disable cgroupv2 and got back to using cgroupv1 by add extra args in your kernel. eg. args=systemd.unified_cgroup_hierarchy=0

You may use grubby to do this:

cgroup v1

Use podman, which is by default installed in your fedora 31 OS. Learn more about podman here: https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/

dfarrell07 commented 4 years ago

My Docker install broke during my Fedora 30->32 update. Moving to Podman was the eaisest solution.

sudo dnf remove docker-ce docker-ce-cli
sudo dnf install podman-docker
rm -rf ~/.config/containers ~/.local/share/containers
podman system migrate
docker run -it --rm alpine /bin/sh

SuperSandro2000 commented 4 years ago

@dfarrell07 If you could actually setup the networking with podman. Never worked for me and no one could help me.

mrswats commented 4 years ago

I just installed docker ce in Fedora 32 and had this issue as well. Running the above partial fix solved the issue for now:

sudo mkdir /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

tuxfan commented 4 years ago

Same here. I used mrswats fix. However, I then ran into problems running dnf install .... This is probably unrelated to this thread, but here's the error output:

docker build --build-arg REPO=https://github.com/tuxfan/flecsi.git --build-arg BRANCH=standalone --no-cache -t laristra/flecsi-tutorial:latest -f legion . Sending build context to Docker daemon 6.144kB Step 1/21 : FROM fedora:latest ---> 920eaf721cff Step 2/21 : RUN dnf install -y clang curl emacs-color-theme flex gcc gcc-c++ gcc-gfortran git graphviz lbzip2 make passwd patch vim-enhanced wget which xz ---> Running in da56cb5bcef3 Fedora Modular 31 - x86_64 0.0 B/s | 0 B 01:00 Errors during downloading metadata for repository 'fedora-modular':

Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] The command '/bin/sh -c dnf install -y clang curl emacs-color-theme flex gcc gcc-c++ gcc-gfortran git graphviz lbzip2 make passwd patch vim-enhanced wget which xz' returned a non-zero code: 1

MightyCreak commented 4 years ago

I tried to install tt-rss on Fedora 32, and none of the workaround here fixed the issue entirely. It did remove the Docker error, but the containers don't seem to be able to work together (I am unsure this is entirely related to this issue though).

The commande line pg_isready -h db -U postgres command line works from within the db container, but not on the other containers, although they can ping the db container successfully.

mmolhoek commented 4 years ago

I just installed docker ce in Fedora 32 and had this issue as well. Running the above partial fix solved the issue for now:
sudo mkdir /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

was all I needed to do to fix it

gilvangobbato commented 4 years ago

I just installed docker ce in Fedora 32 and had this issue as well. Running the above partial fix solved the issue for now:
sudo mkdir /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd
was all I needed to do to fix it

For me this worked in that sesseion, when I restanted my computer Docker keep with this error. To solve it completedly just with this:

I ran into similar issue found a temp fix on another place. Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

For people using fedora 31: Fedora 31 uses cgroupv2 which is not supported by docker yet. So here is what you can do (any one):

Disable cgroupv2 and got back to using cgroupv1 by add extra args in your kernel. eg. args=systemd.unified_cgroup_hierarchy=0

You may use grubby to do this:

Use podman, which is by default installed in your fedora 31 OS. Learn more about podman here: https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/

shonoru commented 4 years ago

Upgraded to Fedora 32, tried steps above. Docker is running,

But now I cannot reach outside of container. It does work with --network host, and it was fine with out these params. Tested on other distros (30, 31, and Ubuntu), it works as well, but only on Fedora 32 it doesn't :shrug:

$ docker run -it alpine /bin/sh

Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
cbdbe7a5bc2a: Pull complete 
Digest: sha256:9a839e63dad54c3a6d1834e29692c8492d93f90c59c978c1ed79109ea4fb9a54
Status: Downloaded newer image for alpine:latest
/ # ping google.com
ping: bad address 'google.com'

Update: found related issue #957

MightyCreak commented 4 years ago

I must say that podman was a drop-in replacement of docker and docker-compose. The output is less nice than docker's, but apart from that, it "just works".

lietu commented 4 years ago

2+ years old issue, which looks like clearly the installation package not doing something required for proper operation.

Installed docker-ce on Fedora 31, docker build . fails with the same error

cgroups: cannot found cgroup mount destination: unknown.

a fix that I imagine is temporary (haven't tried rebooting yet), is to run

sudo mkdir /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

If these were required for Docker to run, why can't these simply be added to the RPM package so they are run when it's installed?

MightyCreak commented 4 years ago

This solution doesn't work in all cases. For instance, I had an issue running the docker-compose.yml for Tiny Tiny RSS. It failed on Fedora 32, but worked perfectly on Ubuntu 18.04 or on Fedora 32 but with Podman (instead of Docker).

wangeugene commented 4 years ago

`[7]+ Stopped sudo yum install docker-ce=17.09.1~ce-0~centos [root@sandbox-hdp ~]# ^C [root@sandbox-hdp ~]# kill -9 55395 [root@sandbox-hdp ~]# sudo yum install docker-ce-17.09.1.ce Loaded plugins: fastestmirror, ovl Loading mirror speeds from cached hostfile epel/x86_64/metalink | 7.3 kB 00:00:00

base: centos.uhost.hk
epel: my.mirrors.thegigabit.com
extras: centos.uhost.hk
ius: mirrors.ircam.fr ` for Centos Users, who encounters the same issue as me, downgrading from docker version 19 -> version 17, fixed my problem

trstruth commented 4 years ago

This seemed to work for me:

In powershell: wsl.exe --shutdown Open a new wsl window and type sudo service docker start

prabuddha-kulatunga commented 4 years ago

This seemed to work for me:

In powershell: wsl.exe --shutdown Open a new wsl window and type sudo service docker start

@trstruth Thanks! worked for me also!

maikell commented 4 years ago

Heads up, I ran in to the same problem. This solution still works on Fedora 32 and Docker version 19.03.9, build 9d988398e7

https://github.com/docker/for-linux/issues/219#issuecomment-622500091

matutetandil commented 4 years ago

IDK if could help, but Docker Play is having the same issue

$ ###############################################################
#                          WARNING!!!!                        #
# This is a sandbox environment. Using personal credentials   #
# is HIGHLY! discouraged. Any consequences of doing so are    #
# completely the user's responsibilites.                      #
#                                                             #
# The PWD team.                                               #
###############################################################
[node1] (local) root@192.168.0.23 ~
docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete 
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for hello-world:latest
docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown.
ERRO[0002] error waiting for container: context canceled 
[node1] (local) root@192.168.0.23 ~
$

marcosnils commented 4 years ago

Seems to working now

moughamir commented 4 years ago

Hi, Solution from this post https://forum.linuxconfig.org/t/how-to-install-docker-on-fedora-31-linuxconfig-org/3605/3 worked for me on Fedora 31 with Docker 19.03.5 and kernel 5.3.11-300.fc31.x86_64:
$ sudo dnf install -y grubby
$ sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
$ sudo reboot
nice.... very nice... Thanks

This is the ultimate solution.

maikell commented 4 years ago

Hi, Solution from this post https://forum.linuxconfig.org/t/how-to-install-docker-on-fedora-31-linuxconfig-org/3605/3 worked for me on Fedora 31 with Docker 19.03.5 and kernel 5.3.11-300.fc31.x86_64:
$ sudo dnf install -y grubby
$ sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
$ sudo reboot
nice.... very nice... Thanks
This is the ultimate solution.

This will revert cgroup to version 1. I don't think this is the way to go. If I understand this correctly:

This command reverts the systemd configuration to use cgroup v1. Other cgroup-v1-based container software including Kubernetes require this command as well.

https://medium.com/nttlabs/cgroup-v2-596d035be4d7 https://www.linuxuprising.com/2019/11/how-to-install-and-use-docker-on-fedora.html

tuxounet commented 4 years ago

Hi, i'm not sure if my fix (based on your comments) is contributive of the issue.

I had the same error message with specific usage of docker-machine on my Mac (Not docker for mac, but Docker Machine with Virtualbox backend)

The issues was caused INSIDE root VM, in boot2docker process, cmount are mounted but cgroups systemd-relative not. (Tiny core Linux or Linux kernel are maybe too old... systemd migration is always a little bit unclear for me)

I fixed it like this : https://github.com/krux-raoui/boot2docker/commit/543ee7107c4c8022311a9b2e096edaf041b25e64#diff-74fe47fbc37b24299edb2eac3e1fa93bR17 (by forking boot2docker repo iso, and rebuild a fresh iso....)

wudstrand commented 4 years ago

I am running on Ubuntu 16.04.6 LTS (Xenial Xerus) and the following worked for me.

$ sudo mkdir /sys/fs/cgroup/systemd
$ sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

tdsan commented 4 years ago

I ran into similar issue found a temp fix on another place. Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

I ran into similar issue found a temp fix on another place. Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

Great work, thank you for that insight, I have justed updated my fedora to run the latest version without any errors. Excellent.

Todd

sgarbour commented 4 years ago

sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

thanks, that solve the issue for me as well.

xgenvn commented 4 years ago

I think this issue can be closed due to many solutions provided under different circumstances. If above comments doesn't help you, please open new issues instead.

reetp commented 4 years ago

I think this issue can be closed due to many solutions provided under different circumstances. If above comments doesn't help you, please open new issues instead.

They are workarounds, not a fix. The bug still exists.

This is probably at the root of it - installing systemd based images on a non systemd host

https://github.com/docker/for-linux/issues/219#issuecomment-404668941

Why won't docker fix it?

stahnma commented 4 years ago

The issue isn't fixed though. This issue is a collection of work-arounds. Closing seems like poor practice @xgenvn.

xgenvn commented 4 years ago

The issue isn't fixed though. This issue is a collection of workarounds. Closing seems like poor practice @xgenvn.

I will reopen, however, I'm not going to see it a good practice either. There're a lot of issues on GitHub just get stale and no solution/workaround provided. Since there is no comment from the dev team, this issue is hardly getting any concern. If you can move ahead with the workarounds, then it's still good to close.

capndave commented 4 years ago

I got this issue on Ubuntu Xenial 16.04 running docker-ce 19.03.02. What's especially weird is that all of my docker containers worked previously and after months all threw a cgroup error on restart/start/build. systemd was already mounted on my Ubuntu build. Rebooting the host machine fixed it.

SuperSandro2000 commented 4 years ago

@capndave Update to Ubuntu 20.04?

pilbender commented 4 years ago

Rebooting the host machine fixes it temporarily. Then the issue pops up again. None of the aforementioned "workarounds" are permanent. Eventually I have to do a reboot. That's the only way to get docker to run my containers again. Restarting the daemon is not enough. Clearing configurations and rebuilding images is not enough. This ought to be elevated to blocker in my opinion. Downgrading to a 17.x.x version is starting to become unrealistic.

Output for "docker version": `Client: Version: 19.03.8 API version: 1.40 Go version: go1.13.10 Git commit: afacb8b Built: Sat Aug 8 20:49:57 2020 OS/Arch: linux/amd64 Experimental: false

Server: Engine: Version: 19.03.8 API version: 1.40 (minimum version 1.12) Go version: go1.13.10 Git commit: afacb8b Built: Sat Aug 8 20:49:37 2020 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.0.2 GitCommit: cfd04396dc68220d1cecbe686a6cc3aa5ce3667c runc: Version: 1.0.0-rc5 GitCommit: 4fc53a81fb7c994640722ac585fa9ca548971871 docker-init: Version: 0.13.0 GitCommit: 949e6fa`

tdsan commented 4 years ago

Mr. WillUdstrand commented on Jun 23 and gave a fix.

$ sudo mkdir /sys/fs/cgroup/systemd $ sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

Did this fix work for you @pilbender ?

T

pilbender commented 4 years ago

@tdsan It didn't. Let me attempt to add a few more bits of noise... I've gotten most of the ideas from following what others have done here.

I've tried downgrading as suggested a couple of years ago to various minor versions of Docker 17.x.x. That has its own issues as other dependent software moves forward.
I've tried the manual mount of the cgroup you're mentioning. Once things have gotten into a locked up state, unmounting and mounting makes no difference. So, I've moved away from that solution.
I've tried supplying kernel args on boot. Specifically appending systemd.unified_cgroup_hierarchy=0 or systemd.unified_cgroup_hierarchy=1 This certainly changed errors but I still ran into them. It takes time (to reinstall lilo in my case) to test these. From my swiss cheese memory, one had the cgroup mount error, one has something else. I can't remember which or the specifics. I'll try to drill down on that if it's somehow helpful.
I fed /etc/docker/daemon.json a new configuration: { "exec-opts": ["native.cgroupdriver=cgroupfs"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2" } This is what I've stuck with as a solution. I'm on the docker version I posted previously, 19.03.8. I'm running kernel version 5.4.19.

I might need to walk back my harshness earlier about it being a blocker. I have several dozen docker images but I'm focused on only a handful at the moment. Here's what I've discovered:

Running docker images from the command line, "docker run...", seems reliable. This was not before the #4 solution I listed above.
Running from docker-compose. Same. Which is expected.
Running minikube... everything goes to hell.

What's weird is I had minikube and its dashboard up and running. I kept firing everything up not realizing that minkkube was causing problems. Once I attempt to start minikube once, that's it. I get the error in this bug thread for everything and I have to do a reboot to get out of it. Rebooting in Linux is like a personal attack on my soul.

Is this a docker issue? I tend to think running that image shouldn't have such miserable effects on everything else. That's the promise I'd expect from running things inside docker.

Is minikube the issue? I'm trying out the docker image of minikube for the first time here. I think I'm going to return to Virtualbox for it. I'm starting to hate minikube, but I need a local instance of Kubernetes to test and write my Terraform scripts. For anyone watching this thread, I'm open to suggestions, especially specifics on successfully running minikube with the docker driver.

PrakashLakhara commented 4 years ago

I ran into similar issue found a temp fix on another place. Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

Hi it is still not working for me. I also rebooted the server. sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd mount: cgroup is already mounted or /sys/fs/cgroup/systemd busy cgroup is already mounted on /sys/fs/cgroup/systemd cgroup is already mounted on /sys/fs/cgroup/freezer cgroup is already mounted on /sys/fs/cgroup/devices cgroup is already mounted on /sys/fs/cgroup/cpu,cpuacct cgroup is already mounted on /sys/fs/cgroup/cpuset cgroup is already mounted on /sys/fs/cgroup/memory

docker run -d -p 8081:80 -p 8443:443 --volumes-from pmm-data --name pmm-server --restart always percona/pmm-server:2 336fab9e9ca431684541b148d7fb3714998a7edd902eae4cd0f2f6800449510f docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown.

SturmB commented 4 years ago

I just ran into this issue.

I recently updated Windows 10 to v2004, upgraded to WSL2, and installed Ubuntu 20.04.

Running an Ansible playbook which starts up several simple containers, it fails at the first one (the official HAProxy image) with this error.

The temporary workaround posted by @dinar-dalvi works for now, but I agree that a permanent solution is needed.

AnthonyAnkrah commented 4 years ago

I ran into similar issue found a temp fix on another place. Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

Thanks @dinar-dalvi your suggestion fixed my issue.

visheshcallin commented 4 years ago

Below fix works for me on Ubuntu 20.04 WSL2 Temp fix: sudo mkdir /sys/fs/cgroup/systemd sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

nmvega commented 4 years ago

I am running on Ubuntu 16.04.6 LTS (Xenial Xerus) and the following worked for me.
$ sudo mkdir /sys/fs/cgroup/systemd
$ sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

This also worked for me on Fedora-32.

docker / for-linux