Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 David Runge (dvzrv) - Friday, 17 January 2020, 11:00 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Maxime Gauduin (Alucryd)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 32
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

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
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
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.

Loading...