[systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats

[Laércio de Sousa]

David,

Looking at GDM debug and gdm-simple-slave.c source file, as well as
"loginctl show-seat" output. I guess that GDM only requests user session
activation for seats with CanMultiSession=yes, but currently systemd-logind
still sets CanMultiSession=no for my non-seat0 seats.

Does seat_can_multi_session() heuristics need some improvement since
generic multi-session was introduced?

I've applied your last patch. I confirm it solves my problem for now.

Thanks for all, and keep the good work!

CANTATE DOMINO CANTICUM NOVUM
QUIA MIRABILIA FECIT

Laércio


2013/11/26 David Herrmann <dh.herrmann at gmail.com>

> Hi
>
> On Tue, Nov 26, 2013 at 11:45 AM, Laércio de Sousa <lbsousajr at gmail.com>
> wrote:
> > Hi David!
> >
> > I just tested your patch, and unfortunately it didn't work. However, I
> guess
> > what could be the question.
> >
> > If I understand correctly, your patch applies for the case we have no
> active
> > session at all in a non-seat0 seat. However, I do have an active session
> in
> > my non-seat0 seat --- the one GDM opens to show the greeter. The
> question is
> > that, when a user logs in at a non-seat0 seat, GDM (or whatever) should
> > activate automatically the new user session, sending the greeter session
> to
> > the background while it's in state "closing", as we have for seat0. In my
> > current setup, it doesn't occur: in a non-seat0 seat, the "closing"
> greeter
> > session remains active, while the new user session starts at background
> > (inactive).
> >
> > If I activate manually the user session (loginctl activate <session>),
> the
> > converse occurs: when the user logs out, its "closing" user session
> remains
> > active, while the new greeter session starts at background (inactive).
> >
> > Just for comparison: if I configure autologin for GDM (to avoid opening
> the
> > greeter session), or use multiseat-patched KDM (which doesn't open
> greeter
> > sessions), the user session starts at foreground, as expected, even
> without
> > this patch.
>
> That gdm behavior is actually weird. It should explicitly request the
> new session to become active. There is no reason for logind to
> *assume* the new session should be activated automatically.. hmm.
>
> The appended patch reverts the new behavior. Can you give it a try? I
> actually cannot get gdm to pick up my additional seats.. and looking
> into the monstrosity called gdm-source-base I have no clue what it
> does. If you can confirm that this resets the behavior, I will apply
> it so we don't break existing setups.
>
> I will figure out something else for new multi-session capable seats.
>
> Thanks
> David
>
>
> diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
> index b30c4ce..ca0e8d7 100644
> --- a/src/login/logind-seat.c
> +++ b/src/login/logind-seat.c
> @@ -413,8 +413,8 @@ int seat_attach_session(Seat *s, Session *session) {
>          seat_send_changed(s, "Sessions", NULL);
>
>          /* On seats with VTs, the VT logic defines which session is
> active. On
> -         * seats without VTs, we automatically activate the first
> session. */
> -        if (!seat_has_vts(s) && !s->active)
> +         * seats without VTs, we automatically activate new sessions. */
> +        if (!seat_has_vts(s))
>                  seat_set_active(s, session);
>
>          return 0;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131126/b1d5abc7/attachment.html>