On Mon, Feb 4, 2019 at 1:28 PM Lennart Poettering <[email protected]> wrote:
> On So, 03.02.19 10:50, Nick Zavaritsky ([email protected]) wrote: > > > Dear systemd developers! > > > > I want to develop something using raw cgroups api, hence I wish to > > enable cgroup delegation on my login session scope (feels like the > > most convenient option). > > > > I am running systemd 237, and I have legacy cgroups disabled > > (cgroup_no_v1=all systemd.unified_cgroup_hierarchy in my kernel boot > > args). > > > > I was unable to figure out how to enable cgroups delegation on a > > session scope, could you please provide some pointers? > > You currently cannot. I figure we could add a concept to pam_systemd.so so > that it can parse arbitrary unit properties from its module command > lines, and that could then include the Delegate= property > too. (i.e. think the stuff you can pass to systemd-run's --property= > switch but denoted in the PAM service fragment). > > However, even if we add that, this would not realistically work: on > cgroupsv2 inner nodes cannot contain processes. That means if a > process X lives in a unit Y and Y has delegation enabled, then X > practically needs to move itself into some subcgroup early on, because > otherwise there can never be populated subcgroups of Y's cgroup, since > X would then populate an inner cgroup, which is after all precisely > what is not allowed. > > So, if you wanted to enable delegation on arbitrary login session > scopes, then this would mean that the shell process (or whatever is > the main process you run inside of it) must be prepared to move itself > out of the session scope's main cgroup early on into some child, > otherwise the delegation is not worth a dime... > > You could of course move the shell process with some external code > from the outside, but yuck: then you come in conflict with the rule > that each cgroup subtree should have a clearly defined manager and not > two managers fight for the same subtree... > > Or to say this differently: unless the shell (or whatever you invoke > as main process of the session scope) is itself cgroups-aware and > manipulates its subtree to take advantage of delegation, delegation in > sessions doesn't really make sense. Or to say this even differently: > Good luck getting a patch for bash upstream that makes it take > possession of its own cgroup subtree and then moves itself into a > subcgroup early on... > > What you can do, is run your code outside of the session scope, for > example through systemd-run or something similar: in this mode you ask > systemd --user for your own service or scope, for which you turn on > delegation. That service/scope is then entirely yours (unlike the > login session scope, which is pretty much owned by the login shell), > hence you can rearange stuff below it like you want. > > > I’ve also tried a few workarounds that came to my mind, but > > surprisingly it didn’t work either. > > > > In particular, systemctl set-property apparently is unaware of > > Delegate= option. > > Delegate is a setting that can only be set when you allocate a unit, > i.e. a-priori. It cannot be changed a-posteriori for an existing unit. > > > Systemd-run —user almost worked (I had to edit > > /lib/systemd/system/[email protected] to enable all available > > controllers on a subtree, my distribution defaults to memory, pids). > > Yeah, we don't enable "cpu" right now by default, since it's too expensive. > > > Unfortunately, systemd-run doesn’t work if I pass —pipe flag. > > Hmm? What's the command line you are using in detail? > > > It fails with 'Failed to create bus connection: No such file or > > directory’ message. According to strace, without —pipe it goes for > > /run/user/1000/systemd/private which works, otherwise > > /run/user/1000/bus is attempted, producing ENOENT. > > That suggests your dbus configuration is borked? Normally the user's > dbus-daemon instance should listen on that socket. > Well, not all distros (e.g. Debian) ship user-bus by default... But if systemctl --user is able to use the private socket for everything else, what prevents it from being used with --pipe? -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
