[systemd-devel] multiple cgroup hierarchies
lennart at poettering.net
Mon May 12 09:12:26 PDT 2014
On Mon, 12.05.14 11:43, Łukasz Stelmach (l.stelmach at samsung.com) wrote:
> 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 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
> 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 Poettering, Red Hat
More information about the systemd-devel