On Thu, 13 Jun 2019 at 15:43:36 +0300, Topi Miettinen wrote: > 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? I don't think so. Consider these two scenarios, which I hope you'll agree should both be allowed: * ssh user@mymachine * with the ssh session still open, log in to gdm on mymachine as user * log in to gdm on mymachine as user * with the X11 or Wayland session still open, ssh user@mymachine If systemd --user is part of a login session, then in each case it would have to be started as a child process of the first way you logged in. This would result in your dbus-daemon --session and your gnome-terminal-server belonging to your ssh login session in the first scenario, and your graphical login session in the second (even though in both cases, gnome-terminal-server is drawing windows onto your graphical login session). It gets even weirder if you log out from the first login session, leaving the second one logged in, and the long-running systemd --user and dbus-daemon --session as members of a login session that no longer exists. The "user-session" concept is primarily useful when login sessions overlap like this: typically you'd have 0-1 graphical login sessions (gdm, etc.), 0 or more remote login sessions (ssh, etc.), 0 or more login sessions on a virtual console or serial console (getty/login) and 0 or more cron jobs. > Or the reverse, start the login session by systemd --user? systemd --user is unprivileged and does not provide a transition from not-logged-in to logged-in state (it isn't in the same position as login, sshd, gdm, cron etc.), so it cannot start login sessions. smcv _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel