[systemd-devel] Controlling user processes with systemd+cgroups

Michal Koutný mkoutny at suse.com
Thu Feb 8 11:30:42 UTC 2018

Hello systemd-devel.

Short summary from the old thread:

On 06.09.15 16:14, Lennart Poettering [1]:
> Ultimately our goal is that you build your tree of slices, and then
> freely attach users, services, containers, VMs to these slices at the
> places you want them. You can already do that nicely for services and
> containers (at least for nspawn containers), but for users this is
> really missing.

The missing piece is thus where to store user->slice mapping (not
necessarily injective as it is now). Then it would be possible to apply
limits _shared in groups_ of users.

Lennart also sketched such information could be in the user database,
although there is no standard way how to obtain that. AFAIK this still
applies and IMO it may take longer to change than comfortable. (Please
enlighten me on whatever I might be missing in this regard.)

I gave a thought to alternatives. They basically rely on GID -- the
information that already can be obtained from a user database in
standard way and it overlaps with most missing use cases.

Variant 1 -- Slice.GroupId= property.

Admins would create unit files for slices specifying this option and
users who are members of any listed groups would have their user
sessions placed into given slice instead of user-$UID.slice.

Variant 2 -- group mode

This would allow admins to switch how user slices are created. By
switching into the group mode (e.g. pam_systemd or logind option) user
sessions would be put into group-$GID-$UID.slice and cgroup
configuration would be then applied to respective group-$GID.slice units.

What are your thoughts on that? Do any other alternatives come to your
mind? Would some of the variants be eventually acceptable to be included?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180208/eff4750a/attachment.sig>

More information about the systemd-devel mailing list