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.

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.

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

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

Hi,

This is probably more a bug in libpam-gnome-keyring since the error
message contains "gkr-pam".
daemon control file), Cc'ed for the following information:

Moreover, there's an upstream bug:

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/28

now closed, but some users reported that the fix did not make the
error disappear.

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