[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