> Wiadomość napisana przez Lennart Poettering <mzerq...@0pointer.de> w dniu > 15.02.2019, o godz. 13:02: > > On Fr, 15.02.19 12:55, Zygmunt Krynicki (m...@zygoon.pl) wrote: > >> I’m happy to work on this issue once it becomes „pressing” and once >> the prerequisites are available. If F30 disables v1 entirely and has >> a kernel where we can get device, freezer and pid controllers then >> it’s „just” a matter of coding. > > The kernel will support both modes for a long time I figure. And so > will systemd. You can switch between both modes at boot time through a > kernel cmdline option, and the change for F30 would be to just default > to a different setting. > > Note that in cgroupsv2 mode systemd will not mount the cgroupv1 > hierchies at all. (You can mount them yourself if you want to > though. For example, systemd-nspawn can optionally provide cgroupsv1 > to container payloads on cgroupsv2 hosts, by simply mounting the > name=systemd hierarchy into the container anyway) > > The "devices" cgroup controller is generally not available on > cgroupsv2. However, there's now a set of bpf hook-ups that you can use > instead and provide pretty much equivalent functionality. (systemd > supports them already).
Indeed, the is a possible way out. It requires some thought on our side to integrate with our current use of v1 devices cgroup, udev rules, snapd side „hot plug” and live changes to running programs (which v1 devices allowed). > > The "freezer" cgroup controller is not available yet on cgroupsv2. But > this is likely going to change soon, but it will be core cgroupsv2 > functionality, not a controller of its own. Until the freezer becomes > available it should be completely fine to simply use SIGSTOP instead, > semantics are not thaaaaat different. We use the freezer for „snap scope” process enumeration (but there are other ways to do that) and to crucially, stop processes while we perform some mount namespace updates, so that there’s less risk of apps attacking the mount code with racing symlinks and what not. Using SIGSTOP for that is, I guess, okay, as long as we can „win” and stop all processes in a given snap reliably enough. > > The "pids" controllers has been available on cgroupsv2 since day one > basically, at the same day it was introduced for cgroupsv1. Yeah. I’m trying to move some of the burden from the freezer to pid so that snapd doesn’t rely on the freezer that much. > > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
