FS#62140 - [lightdm] gkr-pam: unable to locate daemon control file

Attached to Project: Arch Linux
Opened by Kristian (Nexrem) - Monday, 25 March 2019, 22:47 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:15 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 37
Private No

Details

Description:
Systemd journal reports
lightdm[455]: gkr-pam: unable to locate daemon control file

lightdm seems to work fine, allowing me to log in and continue operation.
This issue did not exist in 1:1.28.0-1

Additional info:
* package version(s): 1:1.28.0-3

Steps to reproduce:
1. Let lightdm launch
2. Check systemd journal
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:15 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/lightdm/issues/2
Comment by Jan Przybylak (jp) - Tuesday, 09 April 2019, 17:06 GMT
I also get this error on KDE, so it's not caused by lightdm.
Comment by Kristian (Nexrem) - Wednesday, 10 April 2019, 16:28 GMT
Must be gnome-keyring then
Comment by Jan Przybylak (jp) - Wednesday, 10 April 2019, 17:56 GMT
Could also be PAM
Comment by Lorenzo Porta (Vindex17) - Friday, 26 April 2019, 09:52 GMT Comment by Lex Sheehan (l3x) - Thursday, 12 September 2019, 12:16 GMT
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
Comment by Lex Sheehan (l3x) - Saturday, 14 September 2019, 19:15 GMT
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!
Comment by Lucas Amador de Oliveira (amadorzcv) - Friday, 29 November 2019, 00:21 GMT
I also have this bug. System locks up randomly and i get the gkr-pam: unable to locate daemon control file on journal
Comment by Li (orzogc) - Tuesday, 10 March 2020, 15:35 GMT
It seems like upstream has fixed this bug:
https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/28
Comment by John Bug (johnbug) - Thursday, 14 May 2020, 17:54 GMT
Bug still present.
Comment by Tun Win Naing (twnaing) - Tuesday, 15 September 2020, 02:45 GMT
I have the bug with gnome-keyring 3.36, lightdm 1.30 with Kernel 5.8.6
Comment by John Piers (johnpiers) - Saturday, 10 October 2020, 18:48 GMT
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


Comment by Bart (sleeping) - Monday, 04 January 2021, 17:36 GMT
Same issue with gdm

Bugged when I boot with enabled service
Works if I start service after boot
Comment by Siegfried Metz (NiceGuy) - Tuesday, 16 February 2021, 19:37 GMT
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.
Comment by Arnaud Dovi (cIass101) - Thursday, 13 May 2021, 10:49 GMT
update
Comment by Arnaud Dovi (cIass101) - Friday, 14 May 2021, 03:03 GMT
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.
Comment by Magnus (DeArchDev) - Sunday, 09 January 2022, 09:57 GMT
Can you check if this problem still exists by updating lightdm?
Comment by John Bug (johnbug) - Friday, 22 April 2022, 22:17 GMT
I still get the same message in journalctl.

lightdm[556]: gkr-pam: unable to locate daemon control file
Comment by Mel (Mel) - Saturday, 06 August 2022, 07:58 GMT
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
Comment by Mark Wagie (yochananmarqos) - Saturday, 06 August 2022, 14:39 GMT
@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
Comment by Mel (Mel) - Sunday, 07 August 2022, 10:02 GMT
@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
Comment by Mel (Mel) - Sunday, 07 August 2022, 10:17 GMT
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
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
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.

Loading...