cc @LK4D4 @crosbymichael @rhatdan @lsm5 @jfrazelle

We have many issues with the systemd cgroup driver, mainly caused by actual bugs in systemd's transient units via DBus interface or just general weirdness issues. The move to "cgroupfs by default" was. in my opinion, a very good move until the systemd community is more open to supporting the full set of cgroups Docker supports and providing a much less magical cgroup management systemd.

For example, we've seen cases at SUSE where systemd's reorganisation of cgroups will cause containers set up with --cgroup-parent using the cgroup driver for systemd to get moved to a completely different cgroup (which voids the resource accounting properties of cgroups -- and the security properties of the devices cgroup). This has been fixed upstream, but I have my doubts that this is the last serious issue we'll see with systemd being too magical.

We have setup the default for the Fedora/Centos/RHEL to use systemd. I would rather fix the bugs found rather then drop systemd support, when the kernel moves to a unified view, we need to be ready.

@rhatdan I didn't say that we should drop it. I think that "cgroupfs always unless explicity specified" is a very good default for the moment -- systemd has had many problems (and we barely use it in libcontainer -- it's just used to "alert" systemd to what we are doing and then we use cgroupfs anyway).

I think we'll need to push systemd to improve because when unified cgroups come around, we're going to be SOL if there are any really bad systemd bugs.

See discussion on #20633

Right I understand the problems and why systemd is not implementing parts of the cgroupfs that the systemd and kernel teams are not sure will be their in future kernels. They would prefer people not use them. During the transition period this can be difficult.