On 12.6.2019 22.20, Simon McVittie wrote:
On Wed, 12 Jun 2019 at 19:57:39 +0300, Andrei Borzenkov wrote:
12.06.2019 19:18, Simon McVittie пишет:
systemd user services are not part of a particular login session. They
exist outside all login sessions (look at systemd-cgls).
gnome-terminal surely *is* part of particular login session.
Unfortunately it is spawned by gnome-terminal-server which itself is
started as systemd user session inside sytsemd-user ... session?
The gnome-terminal launcher stub (/usr/bin/gnome-terminal) is part of
a particular login session, but does not persist beyond startup. All it
does is to communicate with gnome-terminal-server and then exit.
gnome-terminal-server exists outside the scope of any particular login
session, and is the component that actually draws windows and runs
a shell.
This has the consequence that GNOME Terminal windows, and the shell that
runs inside them, are drawn onto the X11 or Wayland display that belongs
to a login session, but are not actually part of that login session. You
can see this by looking at the process and cgroup hierarchies.
It's your choice - but you can't have it both ways. The dbus-daemon
can't be both inside a login session, and shared between login sessions.
But that means that as long as there are applications that are part of
user session and started by dbus-daemon, dbus-daemon simply cannot be
part of systemd-user, correct?
I'm very deliberately using the term "login session" because it is a
jargon term identifying a specific thing in the conceptual model used
by systemd-logind, which is essentially the same as the conceptual model
used by non-systemd things like PAM and Linux audit.
A process enters a login session in privileged code (like login(1) or gdm
or similar) at the transition between "not logged in" and "logged in". All
children of a process that is in a login session are in the same login
session; if a process that is not in any login session starts a child
process, the child is also not in any login session, unless the parent
process is privileged and is deliberately starting a new login session.
In systemd, a login session is represented by the session-$N.scope cgroup,
where $N is the session ID.
"User session" means something different: in D-Bus, we use it to refer
to the collection of processes belonging to a user who currently has
at least one login session. It includes all their login sessions (even
if there is more than one), as well as things that belong to that user
but are not in a login session, like systemd --user. In systemd, a user
session is represented by the user-$UID.slice cgroup, where $UID is the
user's numeric uid.
systemd --user is not part of a login session. If you are starting
dbus-daemon --session as a child process of systemd --user, then the
definitions above mean that the dbus-daemon is not part of a login
session either.
The sessions with slightly different scopes might be useful in some
cases. But if this is not the case, would it be possible to unify the
scopes and make systemd --user part of the login session? Now it is
started by PID1, but in that case it probably should be started by
pam_systemd.so or more directly (e.g. /etc/X11/Xsession.d/00systemd)? Or
the reverse, start the login session by systemd --user? I've tried
lightly both approaches but there always seems to be some problems.
-Topi
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
