Wandering Thoughts archives

The root cause of my xdg-desktop-portal problems on a Fedora machine

For some time I've had an odd problem on my work Fedora desktop, where after I logged in the first time I ran one of a number of GUI programs, it would take more than 20 seconds to start with no visible reason for why (the affected programs included Firefox and Liferea). After that 20 seconds, everything was fine and everything started or re-started as fast as it should. This didn't happen on my home Fedora desktop, which has an essentially identical configuration. After I realized that something was wrong and noticed the pattern, I watched journalctl logs during a first program startup and soon found some tell-tale log entries:

10:08:12 dbus-daemon[1220146]: [session uid=19 pid=1220144] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.10' (uid=19 pid=1221915 comm="/u/cks/lib/i386-linux/liferea-git/bin/liferea " label="kernel")
10:08:12 dbus-daemon[1220146]: [session uid=19 pid=1220144] Activating service name='org.freedesktop.portal.Documents' requested by ':1.11' (uid=19 pid=1221921 comm="/usr/libexec/xdg-desktop-portal " label="kernel")
[...]
10:08:12 dbus-daemon[1220146]: [session uid=19 pid=1220144] Activating service name='org.freedesktop.secrets' requested by ':1.11' (uid=19 pid=1221921 comm="/usr/libexec/xdg-desktop-portal " label="kernel")
10:08:12 gnome-keyring-daemon[1220065]: The Secret Service was already initialized
[ ... 20+ second delay ...]
10:08:38 xdg-desktop-por[1221921]: Failed to create secret proxy: Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
10:08:38 xdg-desktop-por[1221921]: No skeleton to export
10:08:38 dbus-daemon[1220146]: [session uid=19 pid=1220144] Successfully activated service 'org.freedesktop.portal.Desktop'

I wasn't happy. My first idea was to remove xdg-desktop-portal entirely, but you can't do that these days. At the time (a couple of weeks ago) I dealt with the problem by chmod'ing all of the xdg-desktop-portal programs to 000, which made the initial activation attempt fail. A few days ago I had to deal with this again (because of a Fedora upgrade to x-d-p that reversed my chmods) and this time I managed to track it down.

(I don't use Flatpaks and other things that xdg-desktop-portal is relevant for, and in any case it doesn't appear to actually work for my odd desktop. This is a known issue, cf, and unfortunately the workarounds don't prevent xdg-desktop-portal from being started.)

In the end, the problem was being caused by a stray gnome-keyring-daemon process that for some reason wasn't cooperating with x-d-p (the g-k-d message in the logs above comes from such a process). This stray process came about because on my work desktop, my /etc/pam.d/login contained a line to start g-k-d on login, through the pam_gnome_keyring PAM module:

session  optional  pam_gnome_keyring.so auto_start

This line wasn't present in my home machine's /etc/pam.d/login, which probably means it dates from before Fedora 15 (timestamps unfortunately provide no clue, as VMWare Workstation appears to touch it when it's installed or upgraded). Commenting out this line (which isn't present on a modern Fedora) fixed my stalling problem, and probably made gnome-keyring-daemon work.

(I don't actually use gnome-keyring-daemon for anything as far as I know. Certainly I don't use it for SSH keys, although I believe it now does actually support ED25519 keys.)

You might at this point reasonably ask why /etc/pam.d/login is relevant at all, instead of /etc/pam.d/xdm or /etc/pam.d/gdm or the like (which do still have an invocation of this module), since it's the PAM module for text logins on the console (or on serial lines). The answer is that I don't use graphical login programs; instead I log in on the text console and then start X from the command line. This also means that my X desktop's D-Bus daemon is not established immediately; instead it's started as part of starting X. It's possible that this caused extra communication difficulties between the running gnome-keyring-daemon and xdg-desktop-portal.

(Clearly x-d-p got g-k-d's attention somehow, but it may not have been through D-Bus. G-k-d does have some sort of control socket, normally found in /run/user/<uid>/keyring/control.)