On Fri, Mar 22, 2013 at 8:57 PM, Lennart Poettering <[email protected]> wrote: > On Fri, 22.03.13 20:24, Kok, Auke-jan H ([email protected]) wrote: > >> >> On Fri, Mar 22, 2013 at 4:11 PM, Lennart Poettering >> <[email protected]> wrote: >> > On Tue, 19.03.13 21:34, Auke Kok ([email protected]) 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 [email protected] (and thus [email protected] 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?
probably >> 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... hmm, if that's the case then we can see if fixing the [email protected] file (and derivatives) to use the username explicitly (fortunately we have the printf specifiers for that now!). I'll stab at it and see if that works. Auke _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
