[systemd-devel] logind: session management

[Lennart Poettering]

On Sat, 19.05.12 14:55, David Herrmann (dh.herrmann at googlemail.com) wrote:

> > 1) Is there any documentation of the logind DBus API? When kmscon is
> > started on a seat, the user can open multiple terminals (similar to
> > tabbed windows in terminal emulators). Should I register a session
> > with logind for each terminal that is opened?
> 
> There seems to be no documentation. However, as far as I can see I
> should register a single session for kmscon regardless how many
> terminals the user opens. The whole kmscon application is then
> considered one session.

The getty should register the session, not kmscon. (I assume that kmscon
does not actually do any authentication on its own, does it?)

> > 2) How does multi-seat handle VT switches? If two seats are active, I
> > guess the xservers share a single VT (lets say vt-7). If one user
> > performs a "chvt 1", does that switch to vt-1 for all users? In other
> > words, if one user switches to kmscon, then all users are switched to
> > kmscon as kmscon and an xserver cannot technically run on the same VT,
> > right?
> 
> After seeing seat_can_multi_session() I can now see that only seat0 is
> considered multi_session capable (as it is registered as
> m->vtconsole). All other seats do not open VTs and do not care for VT
> switches. Hence, only one session can run on these seats.

Yes, this is the current implementation, but this is not exposed in the
bus API so that we can add multi-seat support for non-seat0 later on.

> Knowing that multi-session is not supported on seats != vtconsole, you
> probably don't have such an API. Therefore, I will have a deeper look
> into this and propose one so every seat can be multi-session capable
> (unless you explicitely reject such a feature).

Yes, this is definitely our intention.

> Switching between sessions can then be done via dbus calls instead of
> VT_ACTIVATE on /dev/ttyX.

This might be more complex than it appears at first, since you need to
avoid deadlocks when ksmcon calls into logind, and logind calls into
kmscon....

> > 4) Does systemd implement some internal timeouts for device
> > reassignments? Imagine drm-card0 is assigned to seat5 and the user
> > reassigns it to seat6. If the xserver starts directly up on seat6, it
> > might not be able to get drmMaster for the card (xserver crashes in
> > this case) because the process on seat5 did not release the drmMaster
> > fast enough. The VT-switching logic uses roundtrips to acknowledge
> > release/acquire, however, I cannot see something like this for logind
> > session/device switching.
> 
> That problem still exists but is probably not triggered in real-world
> examples. Anyway, comments are still welcome.

It is a real-life problem I would say, and currently there is no nice
solution for this. It is not such a burning problem so far, since input
devices are multi-open, and hence the race never is visible, but this is
something that needs to be fixed properly eventually.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.