I also get this error on KDE, so it's not caused by lightdm.

Must be gnome-keyring then

Could also be PAM

Source code of the error:
https://github.com/GNOME/gnome-keyring/blob/master/pam/gkr-pam-module.c
Issue on gitlab:
https://gitlab.gnome.org/GNOME/gnome-keyring/issues/28

The last error recorded in my journal before my system locked up:

`Sep 12 07:41:37 k3 lightdm[849]: gkr-pam: unable to locate daemon control file`

Unable to bring up a virtual terminal: Ctrl + Alt + F1, (F1-F6). Mouse frozen, etc.

Happens at random times.

Same behavior for XFCE and GNOME.

Will downgrade lightdm and try for a while to see if the system locks stop.

Kernel: 5.2.13-arch1-1-ARCH x86_64 bits: 64 compiler: gcc v: 9.1.0 Desktop: Xfce 4.14.1 Distro: Arch Linux
lightdm version: 1.30.0

After downgrading from lightdm 1.30.0 to 1.28.0 I have discovered that downgrading did not help. My system is still locking up with the same `Sep 14 15:07:03 k3 lightdm[852]: gkr-pam: unable to locate daemon control file` message.

Any recommendations on how best to troubleshoot this issue?

Thanks!

I also have this bug. System locks up randomly and i get the gkr-pam: unable to locate daemon control file on journal

It seems like upstream has fixed this bug:
https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/28

Bug still present.

I have the bug with gnome-keyring 3.36, lightdm 1.30 with Kernel 5.8.6

Sender lightdm
Time 19:27:25
Message gkr-pam: unable to locate daemon control file
Priority 3

I see the last person who commented was on the 2020-09-15 so don't know if this is still an issue but I presume that it is. My system is also locking up randomly with lightdm gkr-pam: unable to locate daemon control file` message

I'm using gnome-shell 1:3.38.1-1, gnome-keyring 1:3.36.0-1, lightdm 1:1.30.0-4, linux 5.8.14.arch1-1

Same issue with gdm

Bugged when I boot with enabled service
Works if I start service after boot

Planned for Fedora 34 in 2021: https://fedoraproject.org/wiki/Releases/34/ChangeSet#Modular_GNOME_Keyring_services
'The monolithic daemon provided by GNOME Keyring will be split into dedicated sub-daemons, so that they can be consistently managed by systemd.'

Should help in general to fix this annoying error, if it can be implemented in time or there is enough developer effort.

update

Looks like gkr upgrade didn't made it to Fedora34 but seem moved and accpted for Fedora 35

https://fedoraproject.org/wiki/Releases/35/ChangeSet#Modular_GNOME_Keyring_services

---

I tried to temporarily fix this on my system but it's too problematic
The only way I have found to force the variable is to define it as a unit file override Environment=XDG_RUNTIME_DIR=/run/user/1000 but this is very dirty and not usable in multi user environment
I see pam_systemd is set on session in the lightdm's pam and system pam as well but $XDG_RUNTIME_DIR is not set at some point,

I think one possible explanation to this is:

$XDG_RUNTIME_DIR is not set if the current user is not the original user of the session.
https://www.freedesktop.org/software/systemd/man/pam_systemd.html

I'm assuming lightdm runs as root and the fact it opens a session of another user is enough to stops pam_systemd from publishing the variable.

It is just assumptions, because I did not went that far in debugging the internal work of pam_systemd, I have just used a shit tons of debug points in lightdm and I couldn't find any other root cause other than $XDG_RUNTIME_DIR that was indeed not set. lightdm seem to create that $XDG_RUNTIME_DIR at some point to workaround the problem I think, but unfortunately, we don't reach the code that lightdm has in place to create this $XDG_RUNTIME_DIR variable.

Can you check if this problem still exists by updating lightdm?