Arch Linux

noreset

Member

Registered: 2018-09-19

Posts: 53

[SOLVED] gkr-pam: unable to locate daemon control file

More than an issue this would be a clarification question, because it is a matter of understand why the error message appears. It is some time that I'm trying to figure this out.

This is the error in my journal:

gdm-password][683]: gkr-pam: unable to locate daemon control file

In this thread (https://github.com/canonical/lightdm/issues/70) they suggested to set

XDG_RUNTIME_DIR=/run/user/$UID

in /etc/profile to fix it.

Although, the error is still appearing there in the journal, nonetheless, the gnome-keyring-daemon starts properly immediately after having reported to be unable to locate it

nov 27 14:07:01 argon gdm-password][683]: gkr-pam: unable to locate daemon control file
nov 27 14:07:01 argon gdm-password][683]: gkr-pam: stashed password to try later in open session
nov 27 14:07:01 argon gdm-password][683]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring

Is some of you able to give an exhaustive explanation to this?

Last edited by noreset (2020-11-27 20:58:02)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,200

Re: [SOLVED] gkr-pam: unable to locate daemon control file

It's a set of messages that belongs together.

It doesn't find the daemon control file, so it caches the password, and is successful in opening the keyring once the session is properly initialized.

Read, there is no issue and no error and this is of informational value. It could be relevant if the daemon fails to start during session init, as that isn't the case here it can be safely ignored.

The underlying reason is likely that gkr-pam runs before the system  gets around to initializing the rest of the session and starting relevant user services, so the gnome-keyring daemon that is intended to be unlocked does not yet run the first time this check happens.

Last edited by V1del (2020-11-27 15:05:07)

noreset

Member

Registered: 2018-09-19

Posts: 53

Re: [SOLVED] gkr-pam: unable to locate daemon control file

Thanks V1del, got it. Is this entailing that adding

XDG_RUNTIME_DIR=/run/user/$UID

in /etc/profile wasn't necessary?

So, no way to delay gkr-pam from running before these services are initialized? Just because it looks like an inefficient process to me.

Last edited by noreset (2020-11-27 15:19:55)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,200

Re: [SOLVED] gkr-pam: unable to locate daemon control file

Systemd will set that variable on it's own anyway once the session is up, so no setting that won't really help.

The problem from a process perspective is that you are passing a password to PAM and all things hooked into that receive that password. Once it's verified you are you, the rest of the startup can continue, but that is already "after" PAM. and in this particular case  you have something "after" PAM  , the gnome-keyring that still needs your password.

It could also just not log the fact that it doesn't find the daemon and only do so if it fails after the second turnaround, but there are likely reasons for why it was chosen to do so.

noreset

Member

Registered: 2018-09-19

Posts: 53

Re: [SOLVED] gkr-pam: unable to locate daemon control file

Systemd will set that variable on it's own anyway once the session is up, so no setting that won't really help.

The problem from a process perspective is that you are passing a password to PAM and all things hooked into that receive that password. Once it's verified you are you, the rest of the startup can continue, but that is already "after" PAM. and in this particular case  you have something "after" PAM  , the gnome-keyring that still needs your password.

It could also just not log the fact that it doesn't find the daemon and only do so if it fails after the second turnaround, but there are likely reasons for why it was chosen to do so.

Cool, now it is much more clear to me. I can also confirm that setting the variable

XDG_RUNTIME_DIR=/run/user/$UID

was pointless, commenting it out from /etc/profile has made no difference, the gnome-keyring-daemon started properly anyway.

DAC324

Member

Registered: 2020-03-12

Posts: 80

Re: [SOLVED] gkr-pam: unable to locate daemon control file

It's a set of messages that belongs together.

It doesn't find the daemon control file, so it caches the password, and is successful in opening the keyring once the session is properly initialized.

Read, there is no issue and no error and this is of informational value. It could be relevant if the daemon fails to start during session init, as that isn't the case here it can be safely ignored.

The underlying reason is likely that gkr-pam runs before the system  gets around to initializing the rest of the session and starting relevant user services, so the gnome-keyring daemon that is intended to be unlocked does not yet run the first time this check happens.

Thanks a lot also from my side for this explanation.

I have the following in my log:

Jan 20 12:07:01 desktop lightdm[445]: gkr-pam: no password is available for user
Jan 20 12:07:01 desktop kernel: kauditd_printk_skb: 108 callbacks suppressed
Jan 20 12:07:09 desktop kernel: kauditd_printk_skb: 9 callbacks suppressed
Jan 20 12:08:11 desktop gnome-keyring-daemon[461]: asked to register item /org/freedesktop/secrets/collection/default_keyring/9, but it's already registered
Jan 20 12:08:12 desktop gnome-keyring-daemon[461]: asked to register item /org/freedesktop/secrets/collection/default_keyring/9, but it's already registered

Is this connected to the problem discussed here in this thread?

babaliaris

Member

From: Greece

Registered: 2017-09-29

Posts: 88

Website

Re: [SOLVED] gkr-pam: unable to locate daemon control file

Does anyone know if we can hide this message? I really want to see --no-entries-- when running journalctl.

---

Github Account: github.com/babaliaris     Arch General Guidelines
Favourite Distro: archlinux.org                           Arch Wiki

2ManyDogs

Forum Fellow

Registered: 2012-01-15

Posts: 4,645

Re: [SOLVED] gkr-pam: unable to locate daemon control file

Please do not necrobump, especially topics marked [SOLVED].

Closing this old topic.