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

Can not run any docker container (fresh install after reboot) #28109

Closed
bialasjaroslaw opened this Issue Nov 6, 2016 · 23 comments

Comments

Projects
None yet
@bialasjaroslaw

bialasjaroslaw commented Nov 6, 2016

I have installed docker using script provided at https://get.docker.com/. I was able to test docker, but after a while I have to reboot system. After that I could not start any container (even after complete removal and reinstall). I've got the same error each time, and I was unable to find any solution:

docker run -it ubuntu:16.04 /bin/sh

Handler for POST /v1.24/containers
/38a049b5e8da8a720250856ce0e09a4c5a86cf8f1679da05aa79b787869df309/start 
returned error: invalid header field value "oci runtime error: container_linux.go:247: 
starting container process caused \"process_linux.go:359: container init caused 
\\\"rootfs_linux.go:53: mounting \\\\\\\"cgroup\\\\\\\" to rootfs \\\\\\\"/var/lib/docker/devicemapper
/mnt/8c26d2f3ae0b4d69b4375705d3c5b03386e64c9cec69dd012e972f2055acf820/rootfs\\\\\\\" 
at \\\\\\\"/sys/fs/cgroup\\\\\\\" caused \\\\\\\"no subsystem for mount\\\\\\\"\\\"\"\n" 

Linux 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux
Docker version 1.12.3, build 6b644ec

@brennovich

This comment has been minimized.

Show comment
Hide comment
@brennovich

brennovich Nov 6, 2016

I'm getting the same error here:

[brennovich@archpad ~]$ sudo docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c04b14da8d14: Pull complete 
Digest: sha256:0256e8a36e2070f7bf2d0b0763dbabdd67798512411de4cdcf9431a1feb60fd9
Status: Downloaded newer image for hello-world:latest
docker: Error response from daemon: oci runtime error: rootfs_linux.go:53: mounting "/sys/fs/cgroup" to rootfs "/var/lib/docker/devicemapper/mnt/caba129d5183f6cd0b5c933f71aa8699ae593e87c83cadd8a943c403a12f544c/rootfs" caused "no subsystem for mount".

Look at my system details below:

docker info

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-254:1-6818821-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 14.16 MB
 Data Space Total: 107.4 GB
 Data Space Available: 94.14 GB
 Metadata Space Used: 585.7 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge overlay null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.6-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.671 GiB
Name: archpad
ID: Z56X:XKW7:6266:64S6:JLGB:6OX4:IAXL:PVGZ:MJ26:OOXW:DGOG:7LPX
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8
Linux archpad 4.8.6-1-ARCH #1 SMP PREEMPT Mon Oct 31 18:51:30 CET 2016 x86_64 GNU/Linux

Although, I'm able to run containers if I manually mount /sys/fs/cgroup:

docker run --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
 https://hub.docker.com

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/


brennovich commented Nov 6, 2016

I'm getting the same error here:

[brennovich@archpad ~]$ sudo docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c04b14da8d14: Pull complete 
Digest: sha256:0256e8a36e2070f7bf2d0b0763dbabdd67798512411de4cdcf9431a1feb60fd9
Status: Downloaded newer image for hello-world:latest
docker: Error response from daemon: oci runtime error: rootfs_linux.go:53: mounting "/sys/fs/cgroup" to rootfs "/var/lib/docker/devicemapper/mnt/caba129d5183f6cd0b5c933f71aa8699ae593e87c83cadd8a943c403a12f544c/rootfs" caused "no subsystem for mount".

Look at my system details below:

docker info

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-254:1-6818821-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 14.16 MB
 Data Space Total: 107.4 GB
 Data Space Available: 94.14 GB
 Metadata Space Used: 585.7 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge overlay null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.6-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.671 GiB
Name: archpad
ID: Z56X:XKW7:6266:64S6:JLGB:6OX4:IAXL:PVGZ:MJ26:OOXW:DGOG:7LPX
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8
Linux archpad 4.8.6-1-ARCH #1 SMP PREEMPT Mon Oct 31 18:51:30 CET 2016 x86_64 GNU/Linux

Although, I'm able to run containers if I manually mount /sys/fs/cgroup:

docker run --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
 https://hub.docker.com

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/


@bialasjaroslaw

This comment has been minimized.

Show comment
Hide comment
@bialasjaroslaw

bialasjaroslaw Nov 6, 2016

If I mount /sys/fs/cgroup manually it solves the problem I had.
I have also tested this behavior on Arch Linux with kernel 4.7.4 (system is a little bit outdated) and with the same Docker version it works fine without any manual mounting.

bialasjaroslaw commented Nov 6, 2016

If I mount /sys/fs/cgroup manually it solves the problem I had.
I have also tested this behavior on Arch Linux with kernel 4.7.4 (system is a little bit outdated) and with the same Docker version it works fine without any manual mounting.

@mithrandi

This comment has been minimized.

Show comment
Hide comment
@mithrandi

mithrandi commented Nov 7, 2016

Possibly caused by opencontainers/runc#1175 ?

@francois2metz

This comment has been minimized.

Show comment
Hide comment
@francois2metz

francois2metz Nov 7, 2016

Yup, opencontainers/runc#1175 is the root cause (I got his error via docker initially).

francois2metz commented Nov 7, 2016

Yup, opencontainers/runc#1175 is the root cause (I got his error via docker initially).

@francois2metz

This comment has been minimized.

Show comment
Hide comment
@francois2metz

francois2metz Nov 7, 2016

It happens on systems which have systemd 232.

francois2metz commented Nov 7, 2016

It happens on systems which have systemd 232.

@qzio

This comment has been minimized.

Show comment
Hide comment
@qzio

qzio Nov 7, 2016

Contributor

Just want to report that I got this on machines running debian unstable.

Contributor

qzio commented Nov 7, 2016

Just want to report that I got this on machines running debian unstable.

@brennovich

This comment has been minimized.

Show comment
Hide comment
@brennovich

brennovich Nov 7, 2016

Which version of systemd are you using?

On Mon, Nov 7, 2016, 2:26 PM joel hansson notifications@github.com wrote:

Just want to report that I got this on machines running debian unstable.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#28109 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXL9gJ7KcT0qT-n1EnD3s0MQBJ55OUGks5q71EegaJpZM4Kqord
.

brennovich commented Nov 7, 2016

Which version of systemd are you using?

On Mon, Nov 7, 2016, 2:26 PM joel hansson notifications@github.com wrote:

Just want to report that I got this on machines running debian unstable.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#28109 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXL9gJ7KcT0qT-n1EnD3s0MQBJ55OUGks5q71EegaJpZM4Kqord
.

@mithrandi

This comment has been minimized.

Show comment
Hide comment
@mithrandi

mithrandi Nov 7, 2016

systemd 232 was very recently uploaded to Debian Unstable: https://tracker.debian.org/news/812332

mithrandi commented Nov 7, 2016

systemd 232 was very recently uploaded to Debian Unstable: https://tracker.debian.org/news/812332

@wieczorek1990

This comment has been minimized.

Show comment
Hide comment
@wieczorek1990

wieczorek1990 Nov 8, 2016

opencontainers/runc#1175 mentions such solution:

Change GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub so that it looks like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.legacy_systemd_cgroup_controller=yes"

quiet is from default Debian grub install.

Then update grub and reboot:

sudo update-grub
sudo reboot

wieczorek1990 commented Nov 8, 2016

opencontainers/runc#1175 mentions such solution:

Change GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub so that it looks like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.legacy_systemd_cgroup_controller=yes"

quiet is from default Debian grub install.

Then update grub and reboot:

sudo update-grub
sudo reboot
@scoquelin

This comment has been minimized.

Show comment
Hide comment
@scoquelin

scoquelin Nov 8, 2016

@wieczorek1990 error message is not showing up anymore after the fix you provided but now I have some containers exiting with status 139 and nothing is showing up using docker logs mycontainer ...

Linux localhost 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux
Docker version 1.12.3, build 6b644ec
ii  systemd                                       232-2                                amd64        system and service manager

Update : switching back to kernel 4.4 allowed me to workaround the "Exited (139)" issue, no idea why though...

Linux localhost 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux

scoquelin commented Nov 8, 2016

@wieczorek1990 error message is not showing up anymore after the fix you provided but now I have some containers exiting with status 139 and nothing is showing up using docker logs mycontainer ...

Linux localhost 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux
Docker version 1.12.3, build 6b644ec
ii  systemd                                       232-2                                amd64        system and service manager

Update : switching back to kernel 4.4 allowed me to workaround the "Exited (139)" issue, no idea why though...

Linux localhost 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux

martinpitt added a commit to martinpitt/systemd that referenced this issue Nov 9, 2016

core: don't use the unified hierarchy for the systemd cgroup yet
Too many things don't get along with the unified hierarchy yet:

 * opencontainers/runc#1175
 * moby/moby#28109
 * lxc/lxc#1280

So revert the default to the legacy hierarchy for now. Developers of the above
software can opt into the unified hierarchy with
"systemd.legacy_systemd_cgroup_controller=0".
@sej7278

This comment has been minimized.

Show comment
Hide comment
@sej7278

sej7278 Nov 9, 2016

Getting this on Debian Sid, assumed it was a 4.8 kernel thing, but it seems its systemd 232-2

changing grub params is not a fix, its a workaround, has anyone reported to debian bugs?

edit: seems to be fixed in systemd 232-3

sej7278 commented Nov 9, 2016

Getting this on Debian Sid, assumed it was a 4.8 kernel thing, but it seems its systemd 232-2

changing grub params is not a fix, its a workaround, has anyone reported to debian bugs?

edit: seems to be fixed in systemd 232-3

@bialasjaroslaw

This comment has been minimized.

Show comment
Hide comment
@bialasjaroslaw

bialasjaroslaw Nov 9, 2016

edit: seems to be fixed in systemd 232-3

Confirmed. It is working with systemd 232-3 like before previous systemd update

bialasjaroslaw commented Nov 9, 2016

edit: seems to be fixed in systemd 232-3

Confirmed. It is working with systemd 232-3 like before previous systemd update

keszybz added a commit to systemd/systemd that referenced this issue Nov 10, 2016

core: don't use the unified hierarchy for the systemd cgroup yet (#4628)
Too many things don't get along with the unified hierarchy yet:

 * opencontainers/runc#1175
 * moby/moby#28109
 * lxc/lxc#1280

So revert the default to the legacy hierarchy for now. Developers of the above
software can opt into the unified hierarchy with
"systemd.legacy_systemd_cgroup_controller=0".
@martinpitt

This comment has been minimized.

Show comment
Hide comment
@martinpitt

martinpitt Nov 10, 2016

systemd/systemd#4628 reverted this for now, but you can still boot with systemd.legacy_systemd_cgroup_controller=0 to get the unified behaviour; that is useful for developers to make runc/docker/lxc/etc. work with the unified hierarchy eventually.

martinpitt commented Nov 10, 2016

systemd/systemd#4628 reverted this for now, but you can still boot with systemd.legacy_systemd_cgroup_controller=0 to get the unified behaviour; that is useful for developers to make runc/docker/lxc/etc. work with the unified hierarchy eventually.

fbuihuu added a commit to fbuihuu/systemd-opensuse-next that referenced this issue Nov 21, 2016

core: don't use the unified hierarchy for the systemd cgroup yet (#4628)
Too many things don't get along with the unified hierarchy yet:

 * opencontainers/runc#1175
 * moby/moby#28109
 * lxc/lxc#1280

So revert the default to the legacy hierarchy for now. Developers of the above
software can opt into the unified hierarchy with
"systemd.legacy_systemd_cgroup_controller=0".
(cherry picked from commit 843d5ba)
@jamiethermo

This comment has been minimized.

Show comment
Hide comment
@jamiethermo

jamiethermo Dec 14, 2016

I'm getting this on centos 7.2, systemd 219, docker 1.12.2.

Would this be related to the -H fd:// changes in 1.12 or is that a red herring?

jamiethermo commented Dec 14, 2016

I'm getting this on centos 7.2, systemd 219, docker 1.12.2.

Would this be related to the -H fd:// changes in 1.12 or is that a red herring?

@lrepolho

This comment has been minimized.

Show comment
Hide comment
@lrepolho

lrepolho Dec 19, 2016

More people seems to be having the issue here https://forums.docker.com/t/oci-runtime-error-container-init-caused-not-a-directory/23451/8

I could run my container by setting the problematic volume as READ ONLY to share a single file.
From:
volumes:

  • "./config/php-xdebug.ini:/usr/local/etc/php/conf.d/php-xdebug.ini"

To:
volumes:

  • "./config/php-xdebug.ini:/usr/local/etc/php/conf.d/php-xdebug.ini:ro"

lrepolho commented Dec 19, 2016

More people seems to be having the issue here https://forums.docker.com/t/oci-runtime-error-container-init-caused-not-a-directory/23451/8

I could run my container by setting the problematic volume as READ ONLY to share a single file.
From:
volumes:

  • "./config/php-xdebug.ini:/usr/local/etc/php/conf.d/php-xdebug.ini"

To:
volumes:

  • "./config/php-xdebug.ini:/usr/local/etc/php/conf.d/php-xdebug.ini:ro"
@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 19, 2016

Member

@leandrocr that's not related; using a relative path (./) or bind mounting a file to a remote host won't work, therefore the docker daemon creates an empty directory with the name you provided and mounts it in the container (which fails because there's a file on that location).

Please don't put every "daemon failed to start" or "container failed to start" in this thread, as it makes it quickly into a kitchen sink of unrelated issues

Member

thaJeztah commented Dec 19, 2016

@leandrocr that's not related; using a relative path (./) or bind mounting a file to a remote host won't work, therefore the docker daemon creates an empty directory with the name you provided and mounts it in the container (which fails because there's a file on that location).

Please don't put every "daemon failed to start" or "container failed to start" in this thread, as it makes it quickly into a kitchen sink of unrelated issues

keszybz added a commit to systemd/systemd-stable that referenced this issue Jan 31, 2017

core: don't use the unified hierarchy for the systemd cgroup yet (#4628)
Too many things don't get along with the unified hierarchy yet:

 * opencontainers/runc#1175
 * moby/moby#28109
 * lxc/lxc#1280

So revert the default to the legacy hierarchy for now. Developers of the above
software can opt into the unified hierarchy with
"systemd.legacy_systemd_cgroup_controller=0".
(cherry picked from commit 843d5ba)

globin added a commit to NixOS/systemd that referenced this issue Feb 16, 2017

core: don't use the unified hierarchy for the systemd cgroup yet (#4628)
Too many things don't get along with the unified hierarchy yet:

 * opencontainers/runc#1175
 * moby/moby#28109
 * lxc/lxc#1280

So revert the default to the legacy hierarchy for now. Developers of the above
software can opt into the unified hierarchy with
"systemd.legacy_systemd_cgroup_controller=0".
(cherry picked from commit 843d5ba)
@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Mar 8, 2017

This re-appears with Systemd 233:

$ uname -v
#1 SMP Debian 4.9.13-1 (2017-02-27)

$ aptitude versions docker-engine | grep ^i
i  17.03.0~ce-0~debian-stretch debian-stretch 500

$ aptitude versions systemd | grep ^i
i  233-3 experimental 850

$ docker run --rm -it debian:jessie
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"cgroup\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/675c1e80fb22bb74c28a52843dec71d82615f4a541a5028d1f171d85889d8bba/rootfs\\\" at \\\"/sys/fs/cgroup\\\" caused \\\"no subsystem for mount\\\"\"".

Majkl578 commented Mar 8, 2017

This re-appears with Systemd 233:

$ uname -v
#1 SMP Debian 4.9.13-1 (2017-02-27)

$ aptitude versions docker-engine | grep ^i
i  17.03.0~ce-0~debian-stretch debian-stretch 500

$ aptitude versions systemd | grep ^i
i  233-3 experimental 850

$ docker run --rm -it debian:jessie
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"cgroup\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/675c1e80fb22bb74c28a52843dec71d82615f4a541a5028d1f171d85889d8bba/rootfs\\\" at \\\"/sys/fs/cgroup\\\" caused \\\"no subsystem for mount\\\"\"".
@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah
Member

thaJeztah commented Mar 8, 2017

@martinpitt

This comment has been minimized.

Show comment
Hide comment
@martinpitt

martinpitt Mar 8, 2017

@Majkl578 : This got fixed by opencontainers/runc#1266, there just hasn't been a new runc release since then. I backported the fix to to Ubuntu already, but it is not yet fixed in Debian, see the bug report

martinpitt commented Mar 8, 2017

@Majkl578 : This got fixed by opencontainers/runc#1266, there just hasn't been a new runc release since then. I backported the fix to to Ubuntu already, but it is not yet fixed in Debian, see the bug report

@thaJeztah thaJeztah added this to the 17.03.1 milestone Mar 9, 2017

dm0- added a commit to dm0-/coreos-overlay that referenced this issue Mar 10, 2017

sys-apps/systemd: apply CoreOS changes to the v233 ebuild
Changes include:

  * Add cros_workon bits
  * Define and use the symlink-usr flag
  * Drop SELinux policy and udev init scripts dependencies
  * Drop all patches since the source is from Git
  * Switch /etc/resolv.conf to the old one
  * Drop the D-Bus policy path to keep the default
  * Use CoreOS NTP servers
  * Install PAM files into /usr
  * Set the timesyncd epoch
  * Don't use default DNS servers
  * Use legacy cgroups (moby/moby#28109)
  * Rewrite basically the entire install step
  * Drop the systemd-bus-proxy user since the program is long gone
@erickvermot

This comment has been minimized.

Show comment
Hide comment
@erickvermot

erickvermot Apr 6, 2017

I had the same issue using Arch with systemd 232-3.

docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused "mkdir /sys/fs/cgroup/cpuset: no such file or directory"".

upgrading the system got me systemd 232-8, and docker seem to be working again.

erickvermot commented Apr 6, 2017

I had the same issue using Arch with systemd 232-3.

docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused "mkdir /sys/fs/cgroup/cpuset: no such file or directory"".

upgrading the system got me systemd 232-8, and docker seem to be working again.

@blacktop

This comment has been minimized.

Show comment
Hide comment
@blacktop

blacktop Jul 7, 2017

How would I fix this for Docker for Mac?

blacktop commented Jul 7, 2017

How would I fix this for Docker for Mac?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Jul 7, 2017

Contributor

@blacktop Do you you fix what exactly? I'd recommend opening a new issue on github.com/docker/for-mac and give a detailed explanation of what you are seeing.

Thanks!

Contributor

cpuguy83 commented Jul 7, 2017

@blacktop Do you you fix what exactly? I'd recommend opening a new issue on github.com/docker/for-mac and give a detailed explanation of what you are seeing.

Thanks!

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jul 7, 2017

Member

Locking the conversation on this issue, because the original issue reported here was resolved in #31667. If you're still seeing this on an up-to-date docker, please open a new issue with details

Member

thaJeztah commented Jul 7, 2017

Locking the conversation on this issue, because the original issue reported here was resolved in #31667. If you're still seeing this on an up-to-date docker, please open a new issue with details

@moby moby locked and limited conversation to collaborators Jul 7, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.