[systemd-devel] [ANNOUNCE] systemd 190

Lennart Poettering lennart at poettering.net
Mon Sep 24 02:48:03 PDT 2012


On Fri, 21.09.12 23:15, Eelco Dolstra (eelco.dolstra at logicblox.com) wrote:

> 
> Hi,
> 
> On 20/09/12 16:39, Lennart Poettering wrote:
> 
> >         * We will now mount the cgroup controllers cpu, cpuacct,
> >           cpuset and the controllers net_cls, net_prio together by
> >           default.
> 
> Joining the cpuset controller with cpu/cpuacct caused problems on my system
> (NixOS Linux): services, in particular those using "Type=forking", would
> randomly fail to start.  It turns out that this is because systemd uses the cpu
> hierarchy to determine if a service has any running processes left, but the
> addition of cpuset causes adding tasks to control groups to fail with ENOSPC:
> 
> open("/sys/fs/cgroup/cpu/system/nscd.service/control/tasks",
> O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 30
> write(30, "7210\n", 5)                  = -1 ENOSPC (No space left on device)
> 
> Because "tasks" remains empty, systemd concludes that the service has no
> processes left and kills it.  (For the killing it uses
> /sys/fs/cgroup/systemd/system/<service>/cgroup.procs, which *does* have the
> correct contents.)
> 
> The ENOSPC is because the attributes /sys/fs/cgroup/cpu/.../cpuset.{mems,cpus}
> are not set in the per-service cgroups, as required by the cpuset controller.
> Apparently setting /sys/fs/cgroup/cpu/cgroup.clone_children to 1 should cause
> cpuset.{mems,cpus} to be inherited from the top-level cgroup, but as far as I
> can tell, systemd doesn't set clone_children anywhere.  What is the right way to
> deal with this?

Ah, cpuset sucks in this regard. I have now removed the joint moutig of
cpuset again and notified the kernel folks. Let's see...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list