Bug#941675: gkr-pam: unable to locate daemon control file

Felix Zielcke

unread,

Oct 3, 2019, 1:20:03 PM10/3/19

to

Package: libpam-gnome-keyring
Version: 3.34.0-1
Severity: normal

I use MATE and lightdm. With the new version in sid it needs more time
until the desktop appears.

auth.log says:
lightdm: gkr-pam: unable to locate daemon control file

downgrading to the version in testing or commenting out the
libpam_gnome_keyring.so PAM lines in /etc/pam.d/lightdm makes it fast again.

-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpam-gnome-keyring depends on:
ii libc6 2.29-2
ii libpam-runtime 1.3.1-5
ii libpam0g 1.3.1-5
ii libselinux1 2.9-2+b2

Versions of packages libpam-gnome-keyring recommends:
ii gnome-keyring 3.34.0-1

libpam-gnome-keyring suggests no packages.

-- no debconf information

Frank McCormick

unread,

Oct 15, 2019, 9:40:03 AM10/15/19

to

One has to wait until it times out before desktop will appear.

Felix Zielcke

unread,

Oct 23, 2019, 12:00:04 PM10/23/19

to

On Tue, 15 Oct 2019 09:20:36 -0400 Frank McCormick <
fmcco...@videotron.ca> wrote:
> One has to wait until it times out before desktop will appear.
>

It seems like the updated mate-session-manager 1.22.2-2 in sid fixes
the long delay with MATE.
The original Launchpad bug for this is here:

https://bugs.launchpad.net/ubuntu/+source/mate-session-manager/+bug/1846987

But the gkr-pam failure is still in the logs.

Vincent Lefevre

unread,

May 30, 2023, 8:00:04 AM5/30/23

to

Control: found -1 42.1-1

I've also got this error since 3.34.0-1 (exactly), and it still
occurs.

On 2019-10-23 17:37:50 +0200, Felix Zielcke wrote:
> It seems like the updated mate-session-manager 1.22.2-2 in sid fixes
> the long delay with MATE.
> The original Launchpad bug for this is here:
>
> https://bugs.launchpad.net/ubuntu/+source/mate-session-manager/+bug/1846987
>
> But the gkr-pam failure is still in the logs.

I don't use MATE (just FVWM, with logging via lightdm), so, AFAIK,
I've never seen any delay related to that. I'm not aware of any issue,
except that this error is distracting when I look at the logs (it
appears in red in the journalctl output).

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

AlMa

unread,

Jul 17, 2023, 8:10:05 PM7/17/23

to

affects 941675 gdm3
affects 942296 gdm3
found 941675 42.1-1+b2
found 942296 42.1-1+b2
thanks

I use gnome and gdm3. I cannot comment on slow start expressed by the
original posters, except that software upgrades generally slow down
things and sometimes break them. (I can't say I like this.) In my
case, the latest upgrade from Debian 11+12 to clean Debian 12 led to a
perceived longer boot time and X.Org being started instead of Wayland.

Regardless thereof, the message “gdm-password][…]: gkr-pam: unable to
locate daemon control file” is there in Debian 12 bookworm:

Jul 17 12:57:30 AnonymizedMachineName gnome-shell[1135]: Registering
session with GDM
Jul 17 12:57:30 AnonymizedMachineName systemd[1]:
systemd-update-utmp-runlevel.service: Deactivated successfully.
Jul 17 12:57:30 AnonymizedMachineName systemd[1]: Finished
systemd-update-utmp-runlevel.service - Record Runlevel Change in UTMP.
Jul 17 12:57:30 AnonymizedMachineName systemd[1]: Startup finished in
3.672s (kernel) + 8.992s (userspace) = 12.664s.
Jul 17 12:57:32 AnonymizedMachineName NetworkManager[823]: <info>
[1689591452.1845] dhcp6 (wlp179s0): state changed new lease
Jul 17 12:57:42 AnonymizedMachineName systemd[1]:
NetworkManager-dispatcher.service: Deactivated successfully.
Jul 17 12:57:52 AnonymizedMachineName systemd[1]: systemd-fsckd.service:
Deactivated successfully.
Jul 17 12:57:54 AnonymizedMachineName systemd-timesyncd[739]: Contacted
time server 194.25.134.196:123 (2.debian.pool.ntp.org).
Jul 17 12:57:54 AnonymizedMachineName systemd-timesyncd[739]: Initial
clock synchronization to Mon 2023-07-17 12:57:53.855282 CEST.
Jul 17 12:57:58 AnonymizedMachineName systemd[1]:
systemd-localed.service: Deactivated successfully.
Jul 17 12:57:58 AnonymizedMachineName systemd[1]:
systemd-hostnamed.service: Deactivated successfully.
Jul 17 12:57:58 AnonymizedMachineName gdm-password][1902]: gkr-pam:

unable to locate daemon control file

Jul 17 12:57:58 AnonymizedMachineName gdm-password][1902]: gkr-pam:
stashed password to try later in open session
Jul 17 12:57:58 AnonymizedMachineName gdm-password][1902]:
pam_unix(gdm-password:session): session opened for user
AnonymizedUserName(uid=1000) by (uid=0)

The text “gkr-pam: unable to locate daemon control file” is red, i.e.,
indicating an error. Still, various sources on the Web (e.g.,
https://bbs.archlinux.org/viewtopic.php?id=261156 for Arch) say it's not
an error but may become one. This is confusing. The boot, log-in, and
logging should be cleanly rewritten such that, by default, errors are
logged (and shown in red), that non-errors are either not logged or
logged as purely informational text (and shown in gray-white) or as
warnings (and shown in yellow or orange), and that it's possible to
clearly distinguish errors and non-errors.

Gratefully,
AlMa