On Mon, Feb 4, 2019 at 1:28 PM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On So, 03.02.19 10:50, Nick Zavaritsky (mejedi@xxxxxxxxx) 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.
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 systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
