[systemd-devel] Create a new logind session from a systemd --user unit

[Tom Gundersen]

Hi Colin,

I realise this thread may be out-of-date by now, so please excuse me
if I'm commenting on something which has later changed.

On Sun, Aug 4, 2013 at 4:46 PM, Colin Walters <walters at verbum.org> wrote:
> On Tue, 2013-07-30 at 01:02 +0200, Lennart Poettering wrote:
>
>> We are working on this bit by bit. If you want this to go faster, then
>> please work with us, and write patches for libX11 and D-Bus.
>
> Ok, some hacking on the plane on the way to GUADEC got me really far on
> this; then we had a quick face to face to work through some conceptual
> issues.
>
> In the new user@ model, it's very important to note there is only one
> "stub" process per session (at least graphical ones - whether we change
> getty is a whole other topic).  So for graphical, everything is launched
> from user at .service.  The side effect of this is twofold:
>
> 1) Pretty much all the user processes are no longer inside a session
>    at all.
> 2) It is now much harder to log in multiple times graphically; this
>    is kind of a crazy thing to do, but it's still *possible*.  To do
>    so, you wire up your userspace code to set
>    the pile of usual environment variables to override (DISPLAY,
>    DBUS_SESSION_BUS_ADDRESS, etc.)  I can say though at least for
>    GNOME we haven't supported this for years, so it's really not
>    a change.
>
> For for adapting to 1), we agreed on adding the concept of a "primary"
> session, which is basically the first non-tty login.  I've added a small
> API to systemd to look this up, and the patched GNOME to use it
> (although we partially still respect XDG_SESSION_ID).

Hm, I'm not really happy with the notion of a "primary" session,
particularly as it relies on distinguishing between graphical and
non-graphical sessions (where does the line go between a traditional
VT, systemd-consoled, kmscon, wayland, X,...). And also relying on
something being the "first" sounds like it may become confusing for
the user.

Have you considered taking things one step further, and simply force
at most one logind session per user? This would mean that logging in
as the same user the second time means the new login will join the
already existing session. We then get:

 * If at most one of the logins is associated with a seat (and the
rest are remote), things will work just as now.

 * If two logins (of the same user) are associated with different
seats, this is not really supported at the moment, so we could ban it,
or we could simply allow it and temporarily merge the two seats and
let the session controller (window manager) deal with how that should
be presented to the user. This would probably mean that we want
logind's interfaces for getting hardware devices should be per-user,
and not per-session.

 * If two logins (of the same user) are both associated with the same
seat, we'll have to allow switching between the two apps being the
session controller within the same session (this is a common use-case
for when you login once with consoled and once with mutter, or
something like that).

Cheers,

Tom