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?

I still get the same message in journalctl.

lightdm[556]: gkr-pam: unable to locate daemon control file

There's an open issue at https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/41 which proposes addition of systemd user service but it hasn't seen much activity in close to 3 years.
It is unlikely upstream will fix this in a timely manner and arch tends to not go out of it's way to 'fix' something that doesn't really need fixing.

One possible solution is to go about starting it the way Ubuntu does it. They ship systemd unit files started at graphical-session-pre.target.
Since arch for whatever reason doesn't have this target, a modification is in order where WantedBy points to graphical-session.target.
What's confusing is the fact arch doesn't package the gnome-keyring-daemon.{service,socket} files, however the gnome-keyring.install file contains references to it:
# Enable socket by default
systemctl --global enable gnome-keyring-daemon.socket

In case somebody wants to try this approach, the unit files needed:

cat /usr/lib/systemd/user/gnome-keyring-daemon.service

[Unit]
Description=GNOME Keyring daemon

Requires=gnome-keyring-daemon.socket

[Service]
Type=simple
StandardError=journal
ExecStart=/usr/bin/gnome-keyring-daemon --foreground --components="pkcs11,secrets" --control-directory=%t/keyring
Restart=on-failure

[Install]
Also=gnome-keyring-daemon.socket
WantedBy=graphical-session.target


cat /usr/lib/systemd/user/gnome-keyring-daemon.socket

[Unit]
Description=GNOME Keyring daemon

[Socket]
Priority=6
Backlog=5
ListenStream=%t/keyring/control
DirectoryMode=0700

[Install]
WantedBy=sockets.target

I have my system configured to autologin so I had to modify /etc/pam.d/gdm-autologin (I got a different error 'gdm-autologin: gkr-pam: couldn't unlock the login keyring.')
-session optional pam_gnome_keyring.so auto_start
+session optional pam_gnome_keyring.so

@Mel: What are you talking about? The service and socket files are indeed part of the package:

❯ pacman -Ql gnome-keyring | grep keyring-daemon
gnome-keyring /usr/bin/gnome-keyring-daemon
gnome-keyring /usr/lib/systemd/user/gnome-keyring-daemon.service
gnome-keyring /usr/lib/systemd/user/gnome-keyring-daemon.socket
gnome-keyring /usr/share/man/man1/gnome-keyring-daemon.1.gz

@yochananmarqos
~ ▶ pacman -Fl gnome-keyring | grep service
gnome-keyring usr/share/dbus-1/services/
gnome-keyring usr/share/dbus-1/services/org.freedesktop.impl.portal.Secret.service
gnome-keyring usr/share/dbus-1/services/org.freedesktop.secrets.service
gnome-keyring usr/share/dbus-1/services/org.gnome.keyring.service
~ ▶ pacman -Fl gnome-keyring | grep keyring-daemon
gnome-keyring usr/bin/gnome-keyring-daemon
gnome-keyring usr/share/man/man1/gnome-keyring-daemon.1.gz
~ ▶ pacman -Qi gnome-keyring
Name : gnome-keyring
Version : 1:42.1-1
Description : Stores passwords and encryption keys
Architecture : x86_64
URL : https://wiki.gnome.org/Projects/GnomeKeyring
Licenses : GPL LGPL
Groups : gnome
Provides : org.freedesktop.secrets
Depends On : gcr libcap-ng pam openssh
Optional Deps : None
Required By : geary seahorse xdg-desktop-portal-gnome
Optional For : git libsecret
Conflicts With : None
Replaces : None
Installed Size : 3.59 MiB
Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date : Thu 26 May 2022 07:53:16
Install Date : Wed 03 Aug 2022 22:08:50
Install Reason : Installed as a dependency for another package
Install Script : Yes
Validated By : Signature

So I ran pacman -Fyy and now I see the systemd unit files.
~ ▶ pacman -Fl gnome-keyring | grep service
gnome-keyring usr/lib/systemd/user/gnome-keyring-daemon.service
gnome-keyring usr/share/dbus-1/services/
gnome-keyring usr/share/dbus-1/services/org.freedesktop.impl.portal.Secret.service
gnome-keyring usr/share/dbus-1/services/org.freedesktop.secrets.service
gnome-keyring usr/share/dbus-1/services/org.gnome.keyring.service

Checking the package history reveals it was added in version 42.0-1
https://github.com/archlinux/svntogit-packages/commit/654f922e97d5fcc1eb00c3ba1b390e2df77f3e9f

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.