Steps to reproduce the behaviour
- Install a Debian 11 system with gdm 3.38, GNOME 3.38, MATE 1.24.x and systemd
- Log in via ssh (for example assume systemd-logind assigns login session ID 2 for this)
- Log in to MATE, as the same user (for example assume systemd-logind assigns login session ID 4 for this)
- Log out from MATE
- Log in to GNOME, as the same user, without rebooting (for example assume systemd-logind assigns login session ID 6 for this)
- Lock the screen
- Try to unlock the screen
Expected behaviour
- When I log in to MATE,
mate-session-manager uploads some environment variables to dbus-daemon --session via UpdateActivationEnvironment, and either mate-session-manager itself or dbus-daemon passes on those environment variables to systemd --user via SetEnvironment
- Because the
systemd --user and dbus-daemon --session processes are shared between multiple login sessions, these environment variables should not include things that are highly specific to one login session, and in particular XDG_SEAT, XDG_SESSION_ID and XDG_VTNR
- Processes run by
systemd --user, including most of GNOME, do not inherit XDG_SESSION_ID
- In particular, GNOME Shell does not inherit
XDG_SESSION_ID, correctly determines its own systemd-logind session ID (in my example, session ID 6) by querying systemd-logind, and can lock and unlock correctly
Actual behaviour
mate-session-manager sends all environment variables to systemd --user, including XDG_SESSION_ID=4 in my example
- Because the ssh login session keeps
systemd --user alive, XDG_SESSION_ID=4 stays in the activation environment and is "leaked" into the subsequent GNOME session
- GNOME Shell inherits
XDG_SESSION_ID=4 from systemd --user, even though that login session has already ended
- This makes GNOME Shell try to communicate with a logind session that no longer exists, breaking the ability to unlock the screen
- I contributed a change to
gnome-session to work around this, but I don't think it's really a GNOME bug
MATE general version
1.24.1 (not tested with 1.24.2, but none of the changes since 1.24.1 seem like they would affect this)
Package version
1.24.1-1
Linux Distribution
Debian 11
Link to bugreport of your Distribution (requirement)
linuxmint/cinnamon-session#141 (comment) lists some other related fixes in the ancestor project gnome-session. It would be a good idea to incorporate those into mate-session-manager at the same time.
Related bug reports:
Steps to reproduce the behaviour
Expected behaviour
mate-session-manageruploads some environment variables todbus-daemon --sessionviaUpdateActivationEnvironment, and eithermate-session-manageritself ordbus-daemonpasses on those environment variables tosystemd --userviaSetEnvironmentsystemd --useranddbus-daemon --sessionprocesses are shared between multiple login sessions, these environment variables should not include things that are highly specific to one login session, and in particularXDG_SEAT,XDG_SESSION_IDandXDG_VTNRsystemd --user, including most of GNOME, do not inheritXDG_SESSION_IDXDG_SESSION_ID, correctly determines its own systemd-logind session ID (in my example, session ID 6) by querying systemd-logind, and can lock and unlock correctlyActual behaviour
mate-session-managersends all environment variables tosystemd --user, includingXDG_SESSION_ID=4in my examplesystemd --useralive,XDG_SESSION_ID=4stays in the activation environment and is "leaked" into the subsequent GNOME sessionXDG_SESSION_ID=4fromsystemd --user, even though that login session has already endedgnome-sessionto work around this, but I don't think it's really a GNOME bugMATE general version
1.24.1 (not tested with 1.24.2, but none of the changes since 1.24.1 seem like they would affect this)
Package version
1.24.1-1
Linux Distribution
Debian 11
Link to bugreport of your Distribution (requirement)
linuxmint/cinnamon-session#141 (comment) lists some other related fixes in the ancestor project gnome-session. It would be a good idea to incorporate those into mate-session-manager at the same time.
Related bug reports: