>Hm, I wasn't following the kernel ml on this, but from the systemd's >document it follows that there has to be _exactly one_ writer to this >filesystem and this is a restriction forced by the kernel. systemd's >decision is that it will be PID 1, not some other process. On non-systemd >systems that can be some other root process, not necessarily PID 1, but >only one.
Actually, SystemD document actually means «we know no good way to manage this in SystemD-friendly manner without having it all inside a single process» There is a general recommendation that cgroups management is reasonably coordinated, but it is not kernel style to enforce as strict a policy as a single writer process. Strict built-in policies usually come from SystemD and not from kernel, as a rule of the thumb. If we look at the work-in-progress documentation from the kernel developers http://article.gmane.org/gmane.linux.kernel.containers/27701/ the last chapter explicitly discusses much weaker measures. Putting a planned changes section with « Requiring CAP is not a complete solution but should serve as a significant deterrent against spraying cgroup usages in non-privileged programs. » doesn't sound like «a single writer process» to me. > >> >too bad :-) Thanks for the find! >> >> By the way, note that PID-1-only cgroups management is a systemd >> decision, as far as I understand from the kernel mailing list posts, the >> interface will still be a filesystem, and apparently it is OK to >> implement cgroup management by multiple root processes (i.e. not >> a migration to a single open socket). >> >> > >> >On Wed, Jun 4, 2014 at 8:14 AM, Kirill Elagin <[email protected]> >> wrote: >> > >> >> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
