Yesterday I somehow® managed to break my computer.

I'm still not a 100% sure how I managed to do this, but it somehow went like this: During a regular dnf update operation I noticed that I still have fprintd installed, which I do not use since the notebook is in some kind of docking station or my Roost stand most of the time.

So – I went ahead and uninstalled fprintd.

Which lead to a new issue: An occasional

PAM unable to dlopen(/usr/lib64/security/ \
  /usr/lib64/security/ cannot open shared object file: \
  No such file or directory

popping up in the system logs. Not a big deal, but why wouldn't I scratch that itch?

So removed all occurrences of fprintd in my /etc/pam.d/* files. Somehow dnf is supposed to clean up those files after removing a pam package, but there are some known bugs.

While I was cleaning up the fprintd residue, I noticed that my pam config still has gnome-keyring-daemon listed. A leftover from when I was still using GNOME full time. Well, I removed those lines as well.

Those changes went unnoticed until the next dnf update a few days later when I installed a kernel update and had to reboot my machine.

Then things went south

After rebooting my system felt sluggish. Not in a "high system load" way, more like it was constantly running into timeouts when launching apps.

More precisely: when launching GNOME apps like Nautilus, Pavucontrol. They did open up eventually, but only after 30-60 second timeouts.

When my Nextcloud client opened up it's "Cannot connect to nextcloud: the credentials are missing" window, I at least know where to start my search.

Apparently I managed to break GNOME Keyring. I could still launch Seahorse, but I could no longer unlock my login keyring.

Clicking the Unlock button would do nothing. and I would see multiple instances of

gnome-keyring-daemon[61407]: couldn't create system prompt: Timeout was reached
gnome-keyring-daemon[61407]: couldn't initialize prompt: Timeout was reached

errors in my log.

The Culprit

It looks like GNOME keyring daemon could no longer be unlocked since it failed to open it's password prompt. Up until now I was manually unlocking the GNOME Keyring on every login. Weird.

Well, remember how I cleaned up my PAM config earlier? Turns out – GNOME keyring was messing with PAM.

Apparently a lot of tiny little cogs - including DBUS, systemd, GNOME Keyring Daemon and PAM are turning in the background to give users a neat experience.

Which is fine if you never mess with any config file yourself. But I hate those tiny little hidden cogs, since I like to roll my own dotfiles and want to bolt down every lose config flag.

I ended up with the following fix: Up until this week I ran gnome-keyring-daemon from the same script that launched sway. Which worked – yet I still have no clue as to why it worked, since it launched the daemon before anything like $DISPLAY is set.

Now I've moved the initialisation of gnome-keyring-daemon into my regular autostart file, which fires up graphical programs.

The lines now look like this:

dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY > /dev/null
swaymsg exec -- /usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets

(I don't need the SSH agent from GNOME Keyring since I am using customer-specific SSH agents, but that's a whole other story)