Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Regular log in with standard user
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
Slow session opening
Error in the log file  oct. 14 07:50:24 debian sddm-helper[2570]: gkr-pam:
unable to locate daemon control file

   * What outcome did you expect instead?
A smooth log in with no errors

*** End of the template - remove these template lines ***

According to Arch https://bbs.archlinux.org/viewtopic.php?pid=1837490#p1837490
seems linked to this https://gitlab.gnome.org/GNOME/gnome-
keyring/commit/b22d058a055ec3e0f31ae16417f16b42baadb42f

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