Comments

11 Comments

Apologies, user error on my part.

Installed on a vanilla F23 box and did not edit any unit files, and get following error:

sudo systemctl status docker ‚óŹ docker.service - Docker Application Container Engine Loaded: loaded (/etc/systemd/system/docker.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2016-06-08 15:58:16 EDT; 7s ago Docs: http://docs.docker.com Process: 16020 ExecStart=/usr/bin/docker -d $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_NETWORK_OPTIONS $INSECURE_REGISTRY (code=exited, status=125) Main PID: 16020 (code=exited, status=125)

Jun 08 15:58:16 localhost.localdomain systemd[1]: Started Docker Application Container Engine. Jun 08 15:58:16 localhost.localdomain systemd[1]: Starting Docker Application Container Engine... Jun 08 15:58:16 localhost.localdomain docker[16020]: flag provided but not defined: -d Jun 08 15:58:16 localhost.localdomain docker[16020]: See '/usr/bin/docker --help'. Jun 08 15:58:16 localhost.localdomain systemd[1]: docker.service: Main process exited, code=exited, status=125/n/a Jun 08 15:58:16 localhost.localdomain systemd[1]: docker.service: Unit entered failed state. Jun 08 15:58:16 localhost.localdomain systemd[1]: docker.service: Failed with result 'exit-code'.

it looks like the unit should have docker daemon \ and not docker -d \

I tested this with a Kubernetes 1.3 cluster and verified it was functional.

Works for me with kube 1.3 nodes against docker 1.10

This works with kube 1.3 head testing against docker 1.10 and everything is configured as expected.

The package is not using the systemd cgroup driver by default.

This causes unexpected behaviors on upgrades from previous iterations of docker on fedora.

The package is not using the systemd cgroup driver by default.

This causes unexpected behaviors on upgrades from previous iterations of docker on fedora.

I installed the referenced package and spun up a Kubernetes cluster to verify it functioned as expected. I can confirm that this package worked properly.

I verified that this fixed the issue using --cgroup-parent with nested and non-nested slices.

BZ#1320275 --cgroup-parent doesn't work correctly in docker 1.9

The update does not work correctly when using nested slices.

For example,

sudo docker run -c=100 --cgroup-parent=machine-test.slice -it --rm busybox
Warning: '-c' is deprecated, it will be replaced by '--cpu-shares' soon. See usage.
/ # Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
/ # cat /proc/self/cgroup
10:freezer:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
9:devices:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
8:cpuset:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
7:blkio:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
6:perf_event:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
5:hugetlb:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
4:net_cls,net_prio:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
3:memory:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
2:cpu,cpuacct:/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope
1:name=systemd:/machine.slice/machine-test.slice/docker-30e173ed4a7bdb7ad943fc765010b7415f9b41d9d3ffd85f706da0b5db36494b.scope

The cgroup path is only correct for name=systemd, but is wrong for rest.

BZ#1320275 --cgroup-parent doesn't work correctly in docker 1.9

Logged in so my vote would now count.

I can confirm this worked in the default vagrant setup that runs Fedora 21 for the Kubernetes project. I would like to see this available as as possible to keep the Docker version in sync with the rest of the project.