On Mon, 12.05.14 11:43, Łukasz Stelmach (l.stelm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
