Comment 34 for bug 1392176

------- Comment From <email address hidden> 2015-04-07 15:56 EDT-------
(In reply to comment #33)
> Yes Nish, take a look at the full example:
>
> root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
> user.slice/cpuset.cpus
> 0-7
> 0-7
> root@ubuntu1504:/sys/fs/cgroup/cpuset# echo 0 >
> /sys/devices/system/cpu/cpu7/online
> root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
> user.slice/cpuset.cpus
> 0-6
> 0-6
> root@ubuntu1504:/sys/fs/cgroup/cpuset# echo 1 >
> /sys/devices/system/cpu/cpu7/online
> root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
> user.slice/cpuset.cpus
> 0-7
> 0-6
> root@ubuntu1504:/sys/fs/cgroup/cpuset# ps aux | grep cgmanager
> root 5761 0.0 0.0 5120 3072 pts/1 S+ 10:35 0:00 grep
> --color=auto cgmanager
> root 28368 0.0 0.0 4288 3392 ? Ss 10:31 0:00
> /sbin/cgmanager -m name=systemd -M cpuset

I *think* you'd need to have cgmanager's configuration file be correct at boot-time, and have started your system fresh.

The workaround provided by Serge is to simply not mount the cpuset cgroup.

So if you have /sys/fs/cgroup/cpuset (or really, `mount | grep cpuset`, as you can mount it wherever you want) upon boot, then the workaround is not working. Perhaps something else is mounting cpuset.

But I'm a bit worried, doesn't not mounting cpuset mean that containers, for instance, wouldn't work so well?

That is, even if cgmanager doesn't mount the cpuset cgroup, if *anything* mounts it, processes in that cgroup tree will experience the underlying issue, no?