#1040920 gnome-flashback: Gnome flashback unsets XDG_SESSION_ID

Package:
gnome-flashback
Source:
gnome-flashback
Description:
helper application for the GNOME Flashback session
Submitter:
Nikolaus Rath
Date:
2023-07-18 11:42:03 UTC
Severity:
normal
#1040920#5
Date:
2023-07-12 11:49:42 UTC
From:
To:
When starting a Gnome Flashback session, the XDG_SESSION_ID environment
variable is not set. This results on applications that rely on logind to
not behave properly.

Debugging this more closely, I found that XDG_SESSION_ID is still
set in ~/.xsession, but seemingly disappears somewhere in this call:

exec gnome-session --systemd --session=gnome-flashback --disable-acceleration-check
#1040920#10
Date:
2023-07-12 12:00:10 UTC
From:
To:
GNOME Flashback does not do that!

That variable is blacklisted by gnome-session:
https://gitlab.gnome.org/GNOME/gnome-session/-/blob/main/gnome-session/gsm-util.c#L38
#1040920#15
Date:
2023-07-12 12:08:36 UTC
From:
To:
Could this be an unintended side effect of https://salsa.debian.org/gnome-team/gnome-session/-/commit/6f5c3c80be8f92ababd8d6201c5c58e732b47f54?
#1040920#20
Date:
2023-07-12 12:11:05 UTC
From:
To:
Apologies if this came across the wrong way. What I mean is that if I select "Gnome Flashback" as the desired session in GDM, and then start a Terminal, the "XDG_SESSION_ID" variable is not defined.

If I select e.g. "i3" or regular Gnome in GDM, then the variable is defined.

I am not sure what component is at fault, but it is Gnome Flashback users that suffer the consequences.

Best,
-Nikolaus
#1040920#25
Date:
2023-07-12 12:22:30 UTC
From:
To:
Maybe... Why do you need that variable?
#1040920#30
Date:
2023-07-12 12:34:29 UTC
From:
To:
I believe this is critical for any program that wants to interact with logind. For example, xss-lock crashes on unlock without it.
#1040920#35
Date:
2023-07-16 11:22:14 UTC
From:
To:
retitle 1040920 "Gnome flashback breaks out of logind session"
thanks

Upon closer examination, the problem is not that GNome flashback unsets XDG_SESSION_ID, but that it breaks out of the active logind session (so unsetting the variable is, in some way, correct).

In other desktop environments (vanilla i3 as well as regular Gnome), the desktop environment is correctly associated with a logind session:

nikratio@vostro ~> dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID uint32:$fish_pid
method return time=1689506142.664977 sender=:1.6 -> destination=:1.1126 serial=2461 reply_serial=2
   object path "/org/freedesktop/login1/session/_342"

When running Gnome Flashback, however:

ikratio@vostro ~> dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID uint32:$fish_pid
Error org.freedesktop.login1.NoSessionForPID: PID 858156 does not belong to any known session


I don't think this is intentional.. or is it?

Best,
-Nikolaus
#1040920#42
Date:
2023-07-16 19:13:58 UTC
From:
To:
#1040920#47
Date:
2023-07-17 20:02:48 UTC
From:
To:
Can not you get session id from logind manager using
/org/freedesktop/login1/session/auto path?

dbus-send --system --print-reply --dest=org.freedesktop.login1
/org/freedesktop/login1/session/auto org.freedesktop.DBus.Properties.Get
string:org.freedesktop.login1.Session string:Id
#1040920#52
Date:
2023-07-17 20:15:07 UTC
From:
To:
Hi Alberts,

I believe that way you can get *a session id*. However, the fact that the dbus query returns an error means that the various X11 processes (those started by gnome-session as well as those started by the user) are actually not part of that session (or any session, for that matter).

It's not a matter of determining the session id (even though I first thought that), the problem is that the entire gnome flashback session is not associated with a logind session.

Best,
-Nikolaus
#1040920#57
Date:
2023-07-17 20:48:04 UTC
From:
To:
Hi,

I just logged into the Ubuntu GNOME x11 session. The XDG_SESSION_ID
environment variable is not set there either. Also GetSessionByPID for
gnome-shell returns the same error at least for me.

Sorry but you will have to link to relevant documentation if you think that
there are real problems. Also I don't think there is much I can do from
gnome-flashback to change anything...
#1040920#62
Date:
2023-07-18 09:13:22 UTC
From:
To:
Hi Alberts,

One example of a real problem is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040917.

https://manpages.ubuntu.com/manpages/impish/man5/org.freedesktop.login1.5.html also seems pretty clear to me:

In other words, if this DBus request fails then the specified PID is not part of any logind session.

Does that help?

Best,
-Nikolaus
#1040920#67
Date:
2023-07-18 11:38:19 UTC
From:
To:
Hi,

Look at this - https://wiki.gnome.org/Initiatives/SystemdUser and related
merge requests. As far as I understand, current behaviour is expected one
when a session is started/managed by systemd --user. You already confirmed
that with --builtin / --systemd test.

And this confirms above:
https://github.com/systemd/systemd/issues/12399