Edit2: Found what is causing this ! Not lightdm but Arch Linux packaging
On Arch Linux, the file pam/lightdm is replaced by this file trunk/lightdm.pam
Restoring the original file, get ride of the error but it has a new side effect of asking to unlock the keyring when launching google chrome for example.
Currently I’m at loss at finding who’s is responsible of this issue, lightdm team for not covering this case ? Or the Arch Linux team for providing an unsupported pam file.
Edit: Small update, I realized several interesting things while activating the gnome debug logs (Environment=G_MESSAGES_DEBUG=all Environment=G_DEBUG=all), from what I see it is a child process of lightdm (lightdm --session-child X X) which reports that XDG_RUNTIME_DIR is not defined, i will check this tomorrow because I think this variable is lost between parent and child lightdm processes upon opening a session for the lightdm user and that shouldn’t be hard to fix.
Journalctl log
Click to expand!
mai 13 05:34:02 archlinux lightdm[603]: Greeter start authentication for arno
mai 13 05:34:02 archlinux lightdm[603]: Session pid=747: Started with service 'lightdm', username 'arno'
mai 13 05:34:02 archlinux lightdm[603]: Session pid=747: Got 1 message(s) from PAM
mai 13 05:34:02 archlinux lightdm[603]: Prompt greeter with 1 message(s)
mai 13 05:34:02 archlinux lightdm[603]: Continue authentication
mai 13 05:34:02 archlinux lightdm[747]: gkr-pam: unable to locate daemon control file
mai 13 05:34:02 archlinux audit[747]: USER_AUTH pid=747 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux audit[747]: USER_ACCT pid=747 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux lightdm[747]: gkr-pam: stashed password to try later in open session
mai 13 05:34:02 archlinux kernel: audit: type=1100 audit(1620876842.493:60): pid=747 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux kernel: audit: type=1101 audit(1620876842.493:61): pid=747 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux lightdm[747]: Loading users from org.freedesktop.Accounts
mai 13 05:34:02 archlinux lightdm[747]: User /org/freedesktop/Accounts/User1000 added
mai 13 05:34:02 archlinux lightdm[603]: Session pid=747: Authentication complete with return value 0: Success
mai 13 05:34:02 archlinux lightdm[603]: Authenticate result for user arno: Success
mai 13 05:34:02 archlinux lightdm[603]: User arno authorized
mai 13 05:34:02 archlinux lightdm[603]: Greeter requests session cinnamon
mai 13 05:34:02 archlinux lightdm[603]: Seat seat0: Stopping greeter; display server will be re-used for user session
mai 13 05:34:02 archlinux lightdm[603]: Terminating login1 session c1
mai 13 05:34:02 archlinux systemd[1]: Stopping Session c1 of user lightdm.
mai 13 05:34:02 archlinux lightdm[603]: Session pid=636: Sending SIGTERM
mai 13 05:34:02 archlinux lightdm[636]: pam_unix(lightdm-greeter:session): session closed for user lightdm
mai 13 05:34:02 archlinux audit[636]: USER_END pid=636 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_unix,pam_systemd acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux audit[636]: CRED_DISP pid=636 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_env,pam_permit acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux kernel: audit: type=1106 audit(1620876842.912:62): pid=636 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_unix,pam_systemd acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux kernel: audit: type=1104 audit(1620876842.912:63): pid=636 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_env,pam_permit acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
mai 13 05:34:02 archlinux lightdm[603]: Greeter closed communication channel
mai 13 05:34:02 archlinux lightdm[603]: Session pid=636: Exited with return value 1
mai 13 05:34:02 archlinux lightdm[603]: Seat seat0: Session stopped
mai 13 05:34:02 archlinux lightdm[603]: Seat seat0: Greeter stopped, running session
mai 13 05:34:02 archlinux lightdm[603]: Registering session with bus path /org/freedesktop/DisplayManager/Session0
mai 13 05:34:02 archlinux lightdm[603]: Session pid=747: Running command /etc/lightdm/Xsession cinnamon-session-cinnamon
mai 13 05:34:02 archlinux lightdm[603]: Creating shared data directory /var/lib/lightdm-data/arno
mai 13 05:34:02 archlinux lightdm[603]: Session pid=747: Logging to .xsession-errors
From everything I have read on the subject so far, there seem to be several issues raised by this concern.
- Issue is critical: Users are reporting problem upon login or suspending, it doesn’t seem to be from lightdm but another root cause (e.g. As user @xPathin explained, wrong chmod, etc..)
- Issue is low: A recurring error observed in the logs, with no real problem encountered, it seems to be from lightdm (I will develop more on this)
I will expand on the subject of the second minor severity error, as this is the one I see since the first day I use lightdm.
I understand this is a timing problem, the XDG_RUNTIME_DIR env. variable is used at a time before the gnome-kerying even created it.
To workaround it, I haven’t found a simpler approach than setting up the following override to the lightdm.service (tried setting it in /etc/profile.d, /etc/environment, didn’t work better and you should understand why after reading the following journalctl log)
Workaround
It works and is enough to remove the error, but it is very ugly to do as it forces the uid 1000 and is not a suitable solution in a multi-user environment.
Click to expand!
/etc/systemd/system/lightdm.service.d/override.conf
[Service] Environment=XDG_RUNTIME_DIR=/run/user/1000
It is very ugly and wrong in fact, because if you read the journalctl below correctly, the most suitable fix would be to set the UID number of the lightdm user (972 on my system)
XDG_RUNTIME_DIR=/run/user/972
At the time system-logind is creating the New session c1 of user lightdm. and the variable should be cleared when the session c1 is destroyed.
Journalctl log
So I extracted the logs from the journalctl in order to understand what is happening and especially when it is happening, and what I discovered could be interesting in order to fix lightdm so that it stops showing this error.
Click to expand!
14:03:00 dbus-daemon: [system] Activating via systemd: service name='org.freedesktop.Accounts' unit='accounts-daemon.service' requested by ':1.4' (uid=0 pid=601 comm="/usr/bin/lightdm ")
14:03:00 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lightdm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:00 kernel: CRED_ACQ pid=635 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_env,pam_permit acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:00 lightdm: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=972) by (uid=0)
14:03:00 systemd: Starting User Runtime Directory /run/user/972...
14:03:00 systemd-logind: New session c1 of user lightdm.
14:03:00 systemd: Finished User Runtime Directory /run/user/972.
14:03:00 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@972 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:00 systemd: Starting User Manager for UID 972...
14:03:00 kernel: USER_ACCT pid=641 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct="lightdm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:00 kernel: CRED_ACQ pid=641 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=? acct="lightdm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
14:03:00 (systemd): SYSCALL arch=c000003e syscall=1 success=yes exit=3 a0=8 a1=7ffc346fc030 a2=3 a3=3cc items=0 ppid=1 pid=641 auid=972 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="(systemd)" exe="/usr/lib/systemd/systemd" key=(null)
14:03:00 (systemd): pam_env(systemd-user:session): deprecated reading of user environment enabled
14:03:00 kernel: USER_START pid=641 uid=0 auid=972 ses=1 msg='op=PAM:session_open grantors=pam_loginuid,pam_loginuid,pam_keyinit,pam_limits,pam_unix,pam_permit,pam_mail,pam_systemd,pam_env acct="lightdm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:00 systemd: SYSCALL arch=c000003e syscall=321 success=yes exit=8 a0=5 a1=7fff514708c0 a2=78 a3=7fff514708c0 items=0 ppid=1 pid=641 auid=972 uid=972 gid=972 euid=972 suid=972 fsuid=972 egid=972 sgid=972 fsgid=972 tty=(none) ses=1 comm="systemd" exe="/usr/lib/systemd/systemd" key=(null)
14:03:00 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user@972 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:00 systemd: Started Session c1 of user lightdm.
14:03:00 kernel: USER_START pid=635 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_unix,pam_systemd acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:01 systemd: Started D-Bus User Message Bus.
14:03:01 dbus-daemon: [session uid=972 pid=649] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.1' (uid=972 pid=648 comm="/usr/bin/lightdm-webkit2-greeter ")
14:03:01 systemd: Started Accessibility services bus.
14:03:01 dbus-daemon: [session uid=972 pid=649] Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.3' (uid=972 pid=648 comm="/usr/bin/lightdm-webkit2-greeter ")
14:03:01 polkitd: :4: subject=[Subject pid=682 user='lightdm' groups=lightdm seat='seat0' session='c1' local=true active=true]
14:03:07 polkitd: :4: subject=[Subject pid=682 user='lightdm' groups=lightdm seat='seat0' session='c1' local=true active=true]
14:03:10 lightdm: gkr-pam: unable to locate daemon control file
14:03:10 kernel: USER_AUTH pid=749 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:10 kernel: USER_ACCT pid=749 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:10 lightdm: gkr-pam: stashed password to try later in open session
14:03:10 systemd: Stopping Session c1 of user lightdm.
14:03:10 lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
14:03:10 kernel: USER_END pid=635 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_unix,pam_systemd acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:10 kernel: audit: type=1104 audit(1620820990.948:68): pid=635 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_env,pam_permit acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:10 kernel: CRED_DISP pid=635 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_env,pam_permit acct="lightdm" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:10 systemd: session-c1.scope: Consumed 2.733s CPU time.
14:03:10 lightdm: SYSCALL arch=c000003e syscall=1 success=yes exit=4 a0=8 a1=7ffd18fca7f0 a2=4 a3=3e8 items=0 ppid=601 pid=749 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="lightdm" exe="/usr/bin/lightdm" key=(null)
14:03:10 systemd-logind: Removed session c1.
14:03:10 lightdm: pam_unix(lightdm:session): session opened for user arno(uid=1000) by (uid=0)
14:03:10 systemd: Starting User Runtime Directory /run/user/1000...
14:03:10 systemd-logind: New session 2 of user arno.
14:03:10 systemd: Finished User Runtime Directory /run/user/1000.
14:03:10 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:10 kernel: audit: type=1130 audit(1620820990.961:71): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:10 systemd: Starting User Manager for UID 1000...
14:03:10 kernel: USER_ACCT pid=754 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct="arno" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:10 kernel: CRED_ACQ pid=754 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=? acct="arno" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
14:03:10 (systemd): SYSCALL arch=c000003e syscall=1 success=yes exit=4 a0=8 a1=7ffc346fc030 a2=4 a3=3e8 items=0 ppid=1 pid=754 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="(systemd)" exe="/usr/lib/systemd/systemd" key=(null)
14:03:10 (systemd): pam_env(systemd-user:session): deprecated reading of user environment enabled
14:03:10 kernel: USER_START pid=754 uid=0 auid=1000 ses=3 msg='op=PAM:session_open grantors=pam_loginuid,pam_loginuid,pam_keyinit,pam_limits,pam_unix,pam_permit,pam_mail,pam_systemd,pam_env acct="arno" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:10 systemd: SYSCALL arch=c000003e syscall=321 success=yes exit=8 a0=5 a1=7ffccd37c9f0 a2=78 a3=7ffccd37c9f0 items=0 ppid=1 pid=754 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=3 comm="systemd" exe="/usr/lib/systemd/systemd" key=(null)
14:03:11 systemd: Queued start job for default target Main User Target.
14:03:11 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
14:03:11 kernel: USER_START pid=749 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_unix,pam_permit,pam_mail,pam_systemd,pam_env,pam_gnome_keyring acct="arno" exe="/usr/bin/lightdm" hostname=? addr=? terminal=:0 res=success'
14:03:11 kernel: USER_LOGIN pid=749 uid=0 auid=1000 ses=2 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=archlinux addr=? terminal=/dev/tty7 res=success'
14:03:11 lightdm: pam_env(lightdm:session): deprecated reading of user environment enabled
14:03:11 systemd: Created slice User Application Slice.
14:03:11 lightdm: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Since i installed 19.04 I start to getting this error in my syslog sent from gdm-session-wor:
gkr-pam: unable to locate daemon control file
What could be the problem and how to solve it?
asked May 17, 2019 at 23:27
2
This is an informational message; it’s not an issue.
You can see this Arch Linux forum thread for details
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.
Zanna♦
68.9k55 gold badges215 silver badges327 bronze badges
answered Jun 20, 2021 at 13:38
To avoid this message you can do this:
/etc/pam.d/gdm-password
auth optional pam_gnome_keyring.so only_if=gdm
only_if=gdm should do the trick …
Whithout only_if=gdm i got this «issue» and fake unlocked keyring from
systemctlt status gdm3.service
I dont know why …
answered Nov 27, 2022 at 4:44
0
- Index
- » Newbie Corner
- » [SOLVED] gkr-pam: unable to locate daemon control file
#1 2020-11-27 14:33:46
- 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 fileIn this thread (https://github.com/canonical/lightdm/issues/70) they suggested to set
XDG_RUNTIME_DIR=/run/user/$UIDin /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 keyringIs some of you able to give an exhaustive explanation to this?
Last edited by noreset (2020-11-27 20:58:02)
#2 2020-11-27 14:50:55
- V1del
- Forum Moderator
- Registered: 2012-10-16
- Posts: 19,234
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)
#3 2020-11-27 15:17:25
- 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/$UIDin /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)
#4 2020-11-27 15:36:56
- V1del
- Forum Moderator
- Registered: 2012-10-16
- Posts: 19,234
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.
#5 2020-11-27 20:57:16
- noreset
- Member
- Registered: 2018-09-19
- Posts: 53
Re: [SOLVED] gkr-pam: unable to locate daemon control file
V1del wrote:
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/$UIDwas pointless, commenting it out from /etc/profile has made no difference, the gnome-keyring-daemon started properly anyway.
#6 2021-01-20 11:30:19
- DAC324
- Member
- Registered: 2020-03-12
- Posts: 80
Re: [SOLVED] gkr-pam: unable to locate daemon control file
V1del wrote:
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 registeredIs this connected to the problem discussed here in this thread?
#7 2023-01-14 12:38:08
- babaliaris
- Member
- From: Greece
- Registered: 2017-09-29
- Posts: 61
- 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.
#8 2023-01-14 12:46:25
- 2ManyDogs
- Forum Moderator
- Registered: 2012-01-15
- Posts: 4,371
Re: [SOLVED] gkr-pam: unable to locate daemon control file
Please do not necrobump, especially topics marked [SOLVED].
Closing this old topic.
How to post. A sincere effort to use modest and proper language and grammar is a sign of respect toward the community.
|
# |
|
|
Темы: 5 Сообщения: 9 Участник с: 21 января 2022 |
После обновы служба запускается с ошибкой «gkr-pam: unable to locate daemon control file» так менеджер входа запускается при включении, но не блокирует монитор во время простоя рабочего стола, просто экран вырубается через 10 минут, а должно выводить поле ввода пароля. Не пойму в чем проблема, посмотрел файлы в папке /etc/pam.d/ переустановил пакеты
|
|
vs220 |
# |
|
Темы: 22 Сообщения: 8102 Участник с: 16 августа 2009 |
lightdm не блокирует экран , этим занимается блокировщик экрана https://wiki.archlinux.org/title/List_of_applications#Screen_lockers |
|
uape9Oo0 |
# |
|
Темы: 5 Сообщения: 9 Участник с: 21 января 2022 |
как ошибку на скрине решить? |
|
vs220 |
# |
|
Темы: 22 Сообщения: 8102 Участник с: 16 августа 2009 |
Ее не надо решать это нормально, пока юзер не вошел его файлы и не находятся. После входа файл будет найден |
|
uape9Oo0 |
# |
|
Темы: 5 Сообщения: 9 Участник с: 21 января 2022 |
эта запись после обнов появилась, недавно, неделю назад смотрел вывод службы lightdm.service там было все норм |
|
vs220 |
# |
|
Темы: 22 Сообщения: 8102 Участник с: 16 августа 2009 |
У вас логин работает? Служба ключей работает? если да не обращайте внимание это вполне нормально. С блокировкой экрана это не связано. |
Loading