Gnome-keyring and Seahorse 3.34.0 upgrade in Archlinux broke logout / shutdown process.
FredBezies opened this issue · 15 comments
Expected behaviour
Mate-Desktop logout or shutdown without any problem.
Actual behaviour
A dialog box is appearing telling me that at-spi-bus-launcher is not answering, asking me to wait or kill the process to proceed anyway.
Steps to reproduce the behaviour
- Install archlinux with Mate-Desktop
- Be sure to have gnome-keyring and seahorse 3.34.0
MATE general version
1.22.2
Package version
Gnome-keyring 3.34.0
Mate-session-manager 1.22.1
Linux Distribution
Archlinux
Link to downstream report of your Distribution
Bug reported here: https://bugs.archlinux.org/task/63995
More info. Opened a bug on gnome-keyring bug tracker: https://gitlab.gnome.org/GNOME/gnome-keyring/issues/40
Here is a journalctl -b0 | grep gnome-keyring output:
oct. 03 08:46:40 fredo-arch-mate kernel: Initialise system trusted keyrings
oct. 03 08:47:47 fredo-arch-mate gnome-keyring-daemon[917]: The Secret Service was already initialized
oct. 03 08:47:48 fredo-arch-mate gnome-keyring-daemon[917]: The SSH agent was already initialized
oct. 03 08:47:48 fredo-arch-mate gnome-keyring-daemon[917]: The PKCS#11 component was already initialized
oct. 03 09:53:42 fredo-arch-mate gnome-keyring-daemon[25455]: couldn't set environment variable in session: Le délai d’attente est dépassé
oct. 03 09:53:43 fredo-arch-mate gnome-keyring-daemon[25455]: The Secret Service was already initialized
oct. 03 09:53:44 fredo-arch-mate gnome-keyring-daemon[25455]: The PKCS#11 component was already initialized
oct. 03 09:53:44 fredo-arch-mate gnome-keyring-daemon[25455]: The SSH agent was already initialized
Le délai d’attente est dépassé -> The waiting period has expired. A timeout?
According to GNOME's response, keyring needs to be spawned asynchronously, and its output and exit code needs to be handled in the main loop so the DBUS request from gnome-keyring-daemon can be processed.
That is now the latest comment:
I would say it is a bug in the mate session manager. It really needs to be able to handle those dbus calls even when it is trying to start up gnome-keyring at the same time.
The entire point of the patch is that the calls are handled before the application quits (well, before gnome-session registers that the application is quit, but same thing). So if mate session manager waits for the process to quit before handling the dbus calls, then we are in an unsolvable situation.
Actually, the fix in MATE is easier than I thought. The problematic code in MSM is basically do-nothing now, because GNOME_KEYRING_PID exposure was removed from gnome-keyring in 2014, and it can be just removed.
I hope to post a PR soon.
Created a PR: #223
I can confirm the problem with fedora-31-beta.
I was going to review this patch but Ubuntu 19.10 is currently shipping a patched gnome-keyring 3.31 and therefore unaffected.
This change should be fine with gnome-keyring >= 3.11.92
Just for information: Archlinux added this patch for mate-session-manager 1.22.2-1 (https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/mate-session-manager&id=4f82f6addb79099948cb8167c9aaf70e9c0aa2f8) and Manjaro does the same. So this patch is working :)
Please update the Arch patch to the most recent version of #223, this one does not report an error properly if gnome-keyring-daemon crashes on startup.
I confirm the issue in debian testing (with gnome-keyring 3.34.0-1)
Debian stable (with mate 1.20) isn't affected
@raveit65 yes (I didn't test the PR yet)
Please update the Arch patch to the most recent version of #223, this one does not report an error properly if gnome-keyring-daemon crashes on startup.
At Manjaro we updated now to the latest patch.
A dialog box is appearing telling me that at-spi-bus-launcher is not answering, asking me to wait or kill the process to proceed anyway.
Interesting, I saw this in Debian Testing some time before Buster release, but eventually it disappeared (still before Buster release). I thought it was some problem with AT-SPI.
Well, now I have fully updated Debian Testing VM, but can't reproduce the issue. I'll check the patch anyway.