Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#60867 - [gnome-keyring] issue on Plasma Wayland session in sddm

Attached to Project: Arch Linux
Opened by Kyle Tirak (hamsterkill) - Monday, 19 November 2018, 22:01 GMT
Last edited by Antonio Rojas (arojas) - Wednesday, 11 December 2019, 06:30 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


I'm honestly not sure where this bug is coming from since there's several packages that seem to be involved and I don't have another system to test with a different distribution to even know if it's an upstream issue. I'm happy to report this upstream if it is such an issue, I'd just need to know which upstream project is the likely culprit in this case.

When logging in via SDDM into the Plasma Wayland session, gnome-keyring does not seem to work as it is supposed to. Logging in to the standard Plasma session with X still works and automatically unlocks gnome-keyring as expected.

Example error from seahorse:

(seahorse:4926): seahorse-WARNING **: 21:44:20.319: gkr-backend.vala:94: couldn't connect to secret service: Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached

gnome-keyring-daemon is running, however.

Additional info:
gnome-keyring 1:3.28.2-1
sddm 0.18.0-1
plasma-desktop 5.14.3-1
plasma-wayland 5.14.3-1
wayland 1.16.0-1

Steps to reproduce:

Launch SDDM
Choose Plasma Wayland session
Try to use an application with secrets stored in gnome-keyring
This task depends upon

Comment by Kyle Tirak (hamsterkill) - Monday, 26 November 2018, 21:53 GMT
Correction to above: gnome-keyring-daemon does not seem to be getting started by the Plasma Wayland session correctly. The same PAM configuration should be used in both the X and Wayland session cases as far as I know, though:



auth include system-login
-auth optional
-auth optional

account include system-login

password include system-login
-password optional use_authtok

session optional force revoke
session include system-login
-session optional auto_start
-session optional auto_start
Comment by Kyle Tirak (hamsterkill) - Monday, 03 December 2018, 20:13 GMT
Since 5.14.4, gnome-keyring-daemon is back to getting started on login, but not being able to be communicated with on Wayland.
Comment by Kyle Tirak (hamsterkill) - Sunday, 17 February 2019, 19:54 GMT
The source of the issue here appears to be that under X, gnome-keyring-daemon gets properly initialized with a followup call, but not under Wayland.

ps aux | grep keyring (under X):

hamster+ 8307 0.1 0.0 316440 6652 ? Sl 11:43 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
hamster+ 8954 0.0 0.0 242332 7264 ? Sl 11:43 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

Under Plasma Wayland, the second entry (with "--start --foreground --components=secrets") is missing. Attempting to run that command after session start does not appear to resolve the issue, either. Only running the command with "--replace" seems to work (and thus requires inputting the keyring password manually as well).
Comment by Antonio Rojas (arojas) - Tuesday, 10 December 2019, 18:28 GMT
Is this still an issue?
Comment by Kyle Tirak (hamsterkill) - Wednesday, 11 December 2019, 02:11 GMT
There was some action on this upstream a few months ago. I don't have a configuration I can test with anymore to verify, though.

Upstream issue:
Possible fix:
Comment by Bernie Innocenti (codewiz) - Wednesday, 14 April 2021, 04:15 GMT
Just tested with a Plasma Wayland session launched by sddm 0.19. My Plasma is built from git (pre-5.22).

Seahorse works normally.