[systemd-devel] [PATCH] Set cgroup path to uid for user sessions.

Lennart Poettering lennart at poettering.net
Fri Mar 22 20:57:04 PDT 2013

On Fri, 22.03.13 20:24, Kok, Auke-jan H (auke-jan.h.kok at intel.com) wrote:

> On Fri, Mar 22, 2013 at 4:11 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Tue, 19.03.13 21:34, Auke Kok (auke-jan.h.kok at intel.com) wrote:
> >
> >> Without this patch, I'm seeing cgroup paths for user sessions with
> >> both the user name, and the uid created, which can't be intended.
> >>
> >> Spotted through user-session-units use.
> >
> > Hmm, I am missing something here: where do we generate a cgroup path
> > with the uid currently? It's all use rname for the cgroup name right,
> > now, no? What am I missing?
> the user at .service (and thus user-session at .service from user-session-units) have:
> ControlGroup=%R/user/%I/shared cpu:/ ...
> ControlGroupModify=yes
> and we've had to symlink the instances as user@<uid>.service since
> v185 or so..

Hmm, not following... where is this pulled in via a numeric uid, rather
than a user name? The idea was to do this from logind as soon as the
user logs in, but we never did that... So you currently have to do that
manually, but if you do you could use the name here?

> Now, just from a sanity perspective I really think we should be using
> uid's here and not usernames, just like /run/user/<uid>...

This is actually a different case I would claim. The /run/user stuff we
did on special request of the kerberos folks since they wanted to store
stuff there before login, and didn't want to involve nss for that.

Now, /run/user/ is nothing people will likely browse, but this is
different for the cgroup, which can show up in ps, and so on, so i think
we should make this nicely readable by the user...


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list