Re: Processed: Re: Bug#954783: Non-functioning gnome-apps after mate-session due to surviving CLUTTER_BACKEND env var
On Tue, 20 Jun 2023 at 06:42:15 +0000, Mike Gabriel wrote:
> I have now addressed the above issue as proposed by setting
> CLUTTER_BACKEND="x11,*".
I don't think that's a full solution, but it's a mitigation.
Did you try just not setting CLUTTER_BACKEND, as I suggested as the
preferred solution on the bug? As far as I can tell, MATE was only setting
this as a workaround for a bug reported in Ubuntu in 2015. At least one
of the possible root causes for that bug was already fixed, later in 2015.
Since we're now at the beginning of a release cycle, it seems a good time
to remove mysterious workarounds, let testing/unstable users find out
whether the underlying bug still exists, and if it does, get it fixed
properly in the layer that has the bug (whether that means Clutter or
an application). I don't think it should be MATE's job to work around
Clutter bugs, particularly if the workaround can itself cause crashes!
According to codesearch.debian.net, MATE is the only environment that
has felt the need to set CLUTTER_BACKEND: other X11-only environments
like XFCE, LXDE, LXQT and "GNOME on Xorg" don't do that. To me, that
suggests that Clutter applications in X11 sessions must generally work
OK without that workaround.
> However, the real problem it seems is that the CLUTTER_BACKEND variable does
> not get unset on logout/login.
Yes. This is one of the reasons why environment variables are not a
great mechanism. They're OK for things that every desktop environment
and every display manager is going to reset during login (like
DISPLAY and XDG_SESSION_TYPE), but the way they propagate between
components means that setting a workaround like CLUTTER_BACKEND
session-wide is going to have "action at a distance" in ways you likely
didn't intend.
> I tested this with gdm3 and lightdm. As it seems DM-independent I assume
> systemd is involved in this. Is this really how things are supposed to work?
> My understanding of a logout is that all of my session is gone. Fully.
With upstream systemd's defaults, yes, after a logout, your session is
all gone: at the transition between 1 session and 0 sessions per uid,
all your per-user services attached to `systemd --user` (and in particular
`dbus-daemon --session`) are terminated. This means having a ssh or getty
login will keep them alive, but in the common case where you only have
a graphical login, logging out will terminate them.
However, that means that if you're running a screen or tmux session,
after you log out (from MATE or whatever), your session is still gone,
even your screen/tmux session. The systemd upstream view is that this
is correct, and if screen/tmux don't want that (which they don't) then
they should register a new logind session that will keep background
processes alive.
In Debian, to work around the fact that this hasn't been implemented,
we apply build-time configuration to systemd so the default for
KillUserProcesses (as configured in /etc/systemd/logind.conf [Login])
is "no". This means that after you log out from MATE, if there are any
stray processes keeping your session alive, they will not be terminated;
and as long as they're running, your `systemd --user` and `dbus-daemon
--session` will also keep running, which means they remember that MATE
had set CLUTTER_BACKEND.
Any other random environment variables that MATE happens to have set
in /etc/X11/Xsession.d or uploaded into the systemd/D-Bus activation
environment, such as GTK_OVERLAY_SCROLLING, will also "leak" from one
login session into the next.
smcv
Reply to: