[systemd-devel] logind: session management

[David Herrmann]

Hi

I've spent some more time reading systemd/src/login/logind* and could
solve few questions myself, but the multi-session question still
remains:

On Wed, May 16, 2012 at 4:01 PM, David Herrmann
<dh.herrmann at googlemail.com> wrote:
> Hi
>
> I am currently working on kmscon, a user-space VT replacement. In it's
> current state, it simply runs a console emulator on a VT but in the
> end we want it to fully replace CONFIG_VT. To make it multi-seat
> capable I used sd-login.h and it correctly assigns drm-connectors and
> input devices to all available seats. However, I have several
> questions regarding session management (see below).
>
> The idea is to have a single process run all the terminals for all
> available seats. We listen for new and going seats and correctly
> reassign available devices. The user can now use chvt to change
> between their xserver, wayland, kmscon or some other VT. That is, if
> kmscon is not active on seat0, we drop drmMaster (and other devices)
> for seat0 and reqacuire them only when the user switches to kmscon
> again. However, all seats are supposed to be independent in respect to
> VT management (we eventually want to drop it entirely)!
>
> 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.

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

> 3) The idea behind kmscon is to set CONFIG_VT=n (for several different
> reasons but mainly to avoid having UI code in the kernel). Does
> systemd provide a simple way to replace the VT-switching logic? My
> idea was using sd_login_monitor to watch for session changes. If it
> changes, I check with sd_session_is_active() whether my session is
> still active. If not, I stop using the drm, input, etc. devices and
> for instance an xserver can show up. If the user switches to kmscon
> again, I am notified via the sd_login_monitor and
> sd_session_is_active() will be true again and I can start showing up
> again. The interface for switching "VTs"/sessions would then be some
> kind of "sd_activate_session" dbus/library call.
> However, looking at logind sources it seems the "active" logic is
> tightly bound to VTs. I would start working on implementing this,
> however, I'd like to get some review on the idea before I spend too
> much time in it.

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

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

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

> I think that's it for the moment. I would be glad if you can help me
> out with it.
> Regards
> David

Thanks
David