Re: [systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats
Hi On Tue, Nov 26, 2013 at 2:33 PM, Laércio de Sousa wrote: > 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 the confirmation. I pushed the revert to systemd-git so 209 will contain the fix. I will take care that it gets marked as fix for 208, too. Regarding gdm: I guess we cannot rely on CanMultiSession here. It's to risky that we break some other application. But maybe we can allow desktop-managers to modify the CanMultiSession property. So if they explicitly set it to 1 (which we don't do for seats without VTs), we activate the new logic. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats
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
> Hi
>
> On Tue, Nov 26, 2013 at 11:45 AM, Laércio de Sousa
> 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 ),
> 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;
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats
Hi
On Tue, Nov 19, 2013 at 7:13 PM, Laércio de Sousa wrote:
> Hi there!
>
> I'm testing both Fedora 20 Beta and openSUSE 13.1 in my multiseat system
> (with GNOME 3.10, GDM 3.10.0.1 and systemd 208). I'm currently observing a
> strange behaviour which didn't occur in previous distro release (with GNOME
> 3.8.4 and systemd 204).
>
> When I boot my system, gdm greeter session at both seat0 and non-seat0 seats
> are active, as expected. However, when a user logs in at a non-seat0 seat,
> the user session gets inactive. Nevertheless, I can activate it manually
> with command "loginctl activate ", but if that user logs
> out, the new greeter session now becomes inactive.
>
> I suspect this strange behaviour is related to that generic multi-session
> support introduced in systemd 208. I can see that, when a user logs in, the
> greeter and user sessions coexist for a while, one at "closing" state and
> the other at "online" state, depending on whether the user logs in or out.
>
> What could it be? Lack of generic multi-session support in GDM?
I've appended a patch which avoids the situation without an active
session. Can you give it a try? I won't be able to test my multi-seat
setup before Sunday, sorry.
Thanks
David
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index b30c4ce..d52e05b 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -228,7 +228,7 @@ int seat_apply_acls(Seat *s, Session *old_active) {
}
int seat_set_active(Seat *s, Session *session) {
-Session *old_active;
+Session *old_active, *i;
assert(s);
assert(!session || session->seat == s);
@@ -236,6 +236,13 @@ int seat_set_active(Seat *s, Session *session) {
if (session == s->active)
return 0;
+/* if no VTs, avoid having no active session */
+if (!seat_has_vts(s) && !session) {
+LIST_FOREACH(sessions_by_seat, i, s->sessions)
+if (i != s->active)
+session = s->active;
+}
+
old_active = s->active;
s->active = session;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats
Hi there! I'm testing both Fedora 20 Beta and openSUSE 13.1 in my multiseat system (with GNOME 3.10, GDM 3.10.0.1 and systemd 208). I'm currently observing a strange behaviour which didn't occur in previous distro release (with GNOME 3.8.4 and systemd 204). When I boot my system, gdm greeter session at both seat0 and non-seat0 seats are active, as expected. However, when a user logs in at a non-seat0 seat, the user session gets inactive. Nevertheless, I can activate it manually with command "loginctl activate ", but if that user logs out, the new greeter session now becomes inactive. I suspect this strange behaviour is related to that generic multi-session support introduced in systemd 208. I can see that, when a user logs in, the greeter and user sessions coexist for a while, one at "closing" state and the other at "online" state, depending on whether the user logs in or out. What could it be? Lack of generic multi-session support in GDM? CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
