On Fri, Apr 2, 2021 at 7:17 PM Arseny Maslennikov <arseny@xxxxxxxxxxxx> wrote:
Hi everyone!
Recently there's a trend for session-specific processes and services
(and even GUI apps, via `systemd-run --scope') to run as their own user
units on eligible systems/distros, to have a clean and controlled cgroup
hierarchy.
I've been looking at https://systemd.io/DESKTOP_ENVIRONMENTS/ and see no
answer to the following question: how can a process, e. g. gvfs-daemon,
know which logind-session is it run for (for example, to find out the
seat by session ID), if it's actually in a user service unit?
The libsystemd source for sd_pid_get_session(), which is used by gvfs as
of today, gives a hint that function won't work in that case, since a
user service process's /proc/self/cgroup does not contain
"session-XXX.scope".
I don't think most daemons need to know this? Polkit has already changed its policy from allowing actions for specific active session, to allowing them for the whole uid if it owns *an* active session.
Also, part of the trend includes not running more than one graphical session per uid. So the daemon doesn't really need to ask, if there's only one answer. (Note that stuff like $DISPLAY gets imported into systemd --user's environment, to make it available to the services' environment, and you can't make $DISPLAY have two values at once.)
And if the daemon did know "its" session, that sounds like it would make it *less* useful with two sessions, because you would have no way to run a second instance for the other session anyway.
Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
