On Fri, 21.09.12 23:15, Eelco Dolstra ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
