Bug 1796544 - gkr-pam: unable to locate daemon control file
Summary: gkr-pam: unable to locate daemon control file
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 31
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-30 16:50 UTC by Gabriel Zilio
Modified: 2020-12-23 21:38 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 18:40:13 UTC
Type: Bug


Attachments (Terms of Use)
Journalctl of gdm.service with gkr-pam error (4.47 MB, image/jpeg)
2020-03-02 18:48 UTC, Yannik
no flags Details
journalctl -b with relevant data (704.25 KB, text/plain)
2020-05-29 19:25 UTC, mike
no flags Details

Description Gabriel Zilio 2020-01-30 16:50:44 UTC
Description of problem:

After install Fedora 31 Workstation, in Logs, reproduce this red message in gdm-password: gkr-pam: unable to locate daemon control file. 

Version-Release number of selected component (if applicable): GDM 3.34.1


How reproducible:


Steps to Reproduce:
1. Open Terminal
2. Execute: journalctl --unit gdm.service -f

Actual results:

Jan 30 12:28:55 zilione systemd[1]: Starting GNOME Display Manager...
Jan 30 12:28:55 zilione systemd[1]: Started GNOME Display Manager.
Jan 30 12:31:51 zilione gdm-password][1375]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=zilion
Jan 30 12:31:51 zilione gdm-password][1375]: gkr-pam: unable to locate daemon control file
Jan 30 12:32:03 zilione gdm-password][1385]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=zilion
Jan 30 12:32:03 zilione gdm-password][1385]: gkr-pam: unable to locate daemon control file
Jan 30 12:32:14 zilione gdm-password][1391]: gkr-pam: unable to locate daemon control file


Expected results:

Repair this file and find the daemon.


Additional info: Fedora 31 Workstation (with Gnome 3.34.1). Not modified.

Comment 1 Yannik 2020-03-02 18:48:08 UTC
Created attachment 1667044 [details]
Journalctl of gdm.service with gkr-pam error

Comment 2 Yannik 2020-03-02 18:53:38 UTC
I've addded an attachment showing the same gkr-pam error, but with different overall behaviour. In my case, the error appears already in gdm.service and prevents a successful login using GNOME Desktop on Fedora 31 Workstation.

Behaviour of this login loop is: GNOME login shell appears > select account and enter password > password is correct, but screen turns gray, then black > GNOME login shell reappears.

I hope this is also relevant for this bug; if not, just hit me up and I'll file a separate bug report for it

Comment 3 Paul DeStefano 2020-05-01 21:23:27 UTC
Hmm, I can login fine, but I get this error, too.

I cannot seem to lock the screen, though, so I found this while I was researching that problem.

Comment 4 William 2020-05-03 17:20:05 UTC
"upgraded" to fedora 32 on the 1st of May.   Just noticed this error for the first time today in the Logs application.   Not sure if its been happening or not.    (noticed after a reboot)


journalctl --unit gdm.service -f
-- Logs begin at Thu 2020-03-12 19:13:36 EDT. --
May 03 13:09:52 fedora systemd[1]: Stopping GNOME Display Manager...
May 03 13:09:53 fedora gdm[1716]: GdmLocalDisplayFactory: Failed to issue method call: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
May 03 13:09:53 fedora gdm[1716]: Freeing conversation 'gdm-password' with active job
May 03 13:09:53 fedora systemd[1]: gdm.service: Succeeded.
May 03 13:09:53 fedora systemd[1]: Stopped GNOME Display Manager.
-- Reboot --
May 03 13:11:11 fedora systemd[1]: Starting GNOME Display Manager...
May 03 13:11:11 fedora systemd[1]: Started GNOME Display Manager.
May 03 13:11:23 fedora gdm-password][2556]: gkr-pam: unable to locate daemon control file
May 03 13:11:23 fedora gdm-password][2556]: gkr-pam: stashed password to try later in open session
May 03 13:11:27 fedora gdm[1829]: Child process -2027 was already dead.

Comment 5 Forlorn 2020-05-09 20:29:08 UTC
Error appeared after upgrading to F32 on both Fedora PCs.

Comment 6 mike 2020-05-29 19:25:32 UTC
Created attachment 1693520 [details]
journalctl -b with relevant data

Since yesterday I cannot log into Fedora 32 with an Active Directory account. Reinstalled from disk (Fedora-Workstation-Live-x86_64-32-1.6.iso) while preserving /home partition, used realm join again and still unable to log in under a network account. Also tried another account which had not previously logged in and get similar failure.

Seeing Access denied ... 4 (System error) in the journal:

May 29 12:39:26 my-hostname gdm-password][3982]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=my_ad_user
May 29 12:39:26 my-hostname audit[3982]: USER_AUTH pid=3982 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_usertype,pam_usertype,pam_sss,pam_gnome_keyring acct="my_ad_user" exe="/usr/libexec/gdm-session-worker" hostname=my-hostname addr=? terminal=/dev/tty1 res=success'
May 29 12:39:26 my-hostname gdm-password][3982]: gkr-pam: unable to locate daemon control file
May 29 12:39:26 my-hostname gdm-password][3982]: gkr-pam: stashed password to try later in open session
May 29 12:39:26 my-hostname gdm-password][3982]: pam_sss(gdm-password:account): Access denied for user my_ad_user: 4 (System error)
May 29 12:39:26 my-hostname audit[3982]: USER_ACCT pid=3982 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=? acct="my_ad_user" exe="/usr/libexec/gdm-session-worker" hostname=my-hostname addr=? terminal=/dev/tty1 res=failed'
May 29 12:39:26 my-hostname audit[3982]: USER_LOGIN pid=3982 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=27129 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed'

Local user logs in fine.

Another interesting behavior is that when I am logged in under the "my_local_user" account and I use the "Switch User" feature, I attempt to log into the "my_ad_user" account and fail (errors above), then I log back in as "my_local_user" again, successfully, but ten seconds later the screen locks. I unlock with my password again and it doesn't happen again unless I use the "Switch User" feature again.

Comment 7 Thomas Höll 2020-06-11 08:37:11 UTC
I guess was this is somehow related to https://github.com/systemd/systemd/issues/15149. When I login on a console, I get an error from pam_systemd:

Jun 11 10:33:10 my-hostname login[6639]: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=tty3 ruser= rhost= user=my-ad-user
Jun 11 10:33:10 my-hostname audit[6639]: USER_AUTH pid=6639 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_usertype,pam_usertype,pam_sss acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:10 my-hostname audit[6639]: USER_ACCT pid=6639 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname audit[6639]: CRED_ACQ pid=6639 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_localuser,pam_sss acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname login[6639]: pam_systemd(login:session): Failed to get user record: No such proces
Jun 11 10:33:11 my-hostname login[6639]: pam_unix(login:session): session opened for user my-ad-user by LOGIN(uid=0)
Jun 11 10:33:11 my-hostname audit[6639]: USER_START pid=6639 uid=0 auid=1753801108 ses=5 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_unix,pam_umask,pam_lastlog acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname audit[6639]: CRED_REFR pid=6639 uid=0 auid=1753801108 ses=5 msg='op=PAM:setcred grantors=pam_localuser,pam_sss acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname audit[6639]: USER_LOGIN pid=6639 uid=0 auid=1753801108 ses=5 msg='op=login id=1753801108 exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname login[6639]: LOGIN ON tty3 BY my-ad-user@my-ad-domain


Note: I already upgraded to systemd from rawhide

Comment 8 Thomas Höll 2020-06-11 08:43:34 UTC
I forgot to mention that I tried upgrading to pam from rawhide, same behaviour.

Comment 9 Ben Cotton 2020-11-03 17:15:27 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Ben Cotton 2020-11-24 18:40:13 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 11 Michael Vorburger.ch 2020-12-23 21:38:21 UTC
FYI new related Bug 1893131 created.


Note You need to log in before you can comment on or make changes to this bug.