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

[Colin Walters]

[ I'm going to trim the CC, I'm pretty sure everyone who has commented
  so far is on systemd-devel ]

On Wed, 2014-01-08 at 13:55 +0100, David Herrmann wrote:

> This basically defeats the whole purpose of a session. 

A lot of it, yes.  The session becomes:

* A refcount on the user at .service
* A claim of particular devices (tty, X server)

> If you now do
> session.kill(), you kill both logins. That's not intentional, I guess.

No.  The only process actually in the session cgroup would be a stub.
Asking logind to kill it would cause it to release the fd and hence drop
a ref on the user at .service.

Only once all sessions are closed would the user at .service terminate.

> >  * 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.

Yeah...this bit is tricky.  For the case of GNOME where it's simply
not supported to log in multiple times, all we need is a mechanism to
discover the X server that gdm spawned (not as part of the session or
user at .service).

The way that works in my prototype patches is that GDM sets the
x11-display property via PAM, and then systemd writes that to
$XDG_RUNTIME_DIR.  From there, libX11 can pick it up automatically.

Now, for "session controllers" that want to support multiple logins, it
gets far more complex.  I think they'd have to do something like what
you were saying with double templating (somecontroller@<num>.service).

Or as I say below, these controllers just stay as they are today.

> I talked to Jasper about this shortly. I really think we need to
> discuss this at FOSDEM. What he said is that they try to ditch
> sessions entirely and move to "user-based sessions" instead. So if you
> login multiple times as the same user, you always join the same
> session (or are rejected, whatever your policy is).

A lot hinges on the precise meaning of "join" here.  Presently, gdm will
just VT-switch you to your original X server if you try to log in again.

> * Multi-seat: You cannot login as the same user on two seats
> simultaneously. This would require running "systemd --user" twice for
> the same user. I'm not sure whether that is possible? Same requirement
> would be given for the user-bus, etc.. We could use unit-templates,
> something like systemd-consoled@<num>.<seat>.service. However,
> multi-layer templates seem cumbersome. 

Or "session controllers" that want to do this simply don't run per user;
they just continue to have all of their processes in the session cgroup
and work just as they do today.  I can't think of a problem with that.

> * Session-assignment: This is the bigger problem, imho. If we run
> processes as systemd --user units, these services are childs of
> systemd, not of gnome-session or else. As systemd does not run in a
> session, the units itself cannot inherit a session. So we really
> destroy the session concept then for anything that runs for the whole
> user.

Yes, as I said; I think we'll all have to come to grips with the idea
that a session is just a refcount on user at .service with some metadata;
it no longer holds the process tree.