<div dir="ltr"><div dir="ltr">On Mon, Feb 4, 2019 at 1:28 PM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On So, 03.02.19 10:50, Nick Zavaritsky (<a href="mailto:mejedi@gmail.com" target="_blank">mejedi@gmail.com</a>) 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/user@.service 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. </blockquote><div> </div><div>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?</div><div> </div></div>-- <div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>