[systemd-devel] Cgroups v2 delegation on a session scope

[Mantas Mikulėnas]

On Mon, Feb 4, 2019 at 1:28 PM Lennart Poettering <lennart at poettering.net>
wrote:

> On So, 03.02.19 10:50, Nick Zavaritsky (mejedi at gmail.com) 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 at .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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190204/108c1967/attachment.html>