[systemd-devel] multiple cgroup hierarchies

[Lennart Poettering]

On Mon, 12.05.14 11:43, Łukasz Stelmach (l.stelmach at samsung.com) wrote:

> Hello.
> 
> I've tried to update systemd to version 212 in Tizen. After I resolved
> usual building problems and managed to make my device boot, I hit a
> number of "Failed to create cgroup ..." messages. It took me some time
> to find the reason (ah, the loveliness of parallel processing) which
> appears to be a piece of software that tries to set up its own cgroup
> hierarchy and destroys what systemd has done (definitely a
> bug). However, I can see a problem with systemd too.
> 
> At some point before v212 Lennart decided[1] to lock /sys/fs/cgroup tmpfs
> instance mounting it read-only to prevent some issues with shmem.
> However this commit also prevents other processes from creating their
> own cgroup hierarchies. My question is: is it deliberate? 

Well, yes. That said, people can simply remount the dir writable agan and
then do whatever they want...

I just wanted to make sure that no accidental changes take place on the
dir.

> Is there (going to be?) a way to for "third-party" software to have
> their own cgroup hierarchies next to systemd in /sys/fs/cgroup despite
> of it being remounted read-only?

Well, sure, they can remount it writable, adn then add it there. That
said, given that that would be a private hierarchy, there's really not
much point in even mounting it to /sys/fs/cgroup/<foobar>, it could just
as well place it in /run/<foobar>/mycgrouptree...

In general though, be prepare though that after the kernel cgroup rework
there will be only a single cgroup tree, so this entire thing will not
work in the long run...

Lennart

-- 
Lennart Poettering, Red Hat