[SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

aegis · 2023-11-12 06:54:22

Not sure if this is Arch specific or a GNOME issue, but it started happening within the past month or so. My Arch laptop runs gnome and I have Fingerprint logins enabled as well as Password + U2F. Both have worked fine for many years. Because of this setup, I am immediately requested to enter a password when initially logging into GNOME via GDM. That unlocks my keyring and from that point on I can use my fingerprint to login without any additional requests to unlock the keyring until I shutdown or restart.

However, a few weeks ago I started getting 2 requests to enter the gnome keyring password:

https://imgur.com/a/FbOpLKG

After entering in my password on the initial dialog box, I still get the following request to enter the password again:

https://imgur.com/a/T11xfur

If I don't enter this password successfully on the second request, Brave browser will not start at all.

The request prompt also appears to use a black and white version of the Bitwarden symbol, but I even uninstalled the desktop version of Bitwarden to see if that fixed it and it still showed up.

Any help would be greatly appreciated.

Last edited by aegis (2024-01-11 18:21:56)

seth · 2023-11-12 09:24:18

Brave browser will not start at all

Not sure whether this is related to gkr or brave here: https://bbs.archlinux.org/viewtopic.php?id=288822
Can you still access the keyring otherwise after providing the key once? (eg. with gnome-keyring)
What happens if you cancel the first request?

aegis · 2023-11-12 17:21:49

Seth,

Yes, I have no problem with accessing the keyring. If I enter the password into the first prompt, that prompt disappears and the one behind takes focus. Regardless of whether or not I enter the password in the first prompt (even if I cancel it) the second prompt takes focus immediately afterwards.

Now, if I don't put in the correct password in the second (greyish) prompt, no error is produced but Brave browser will never open subsequently.

If I put the password in the second prompt, everything works normally.

I just want to stop being asked twice and having these 2 prompts pop up simultaneously. Previously just the first prompt requesting to unlock the keyring would display, and it worked fine.

seth · 2023-11-12 17:35:52

Do you somehow autostart brave or other browsers/electron clients (discord, spotify and whatnot) with the session?
Try to configure the browser to use the internal keyring (se prev link) and whether that makes the dialog go away.

aegis · 2023-11-13 02:30:23

Seth,

I have tried to determine is Brave is autostarting somehow and I can't find anything that indicates it is. Also, I don't know for sure that the second prompt is directly related to Brave. I just have come to find that Brave fails to start when I don't input the password in that prompt.

It's kind of frustrating because I don't know why this all of a sudden started.

tethys · 2023-11-13 07:07:42

I had a similar issue with jxbrowser and chromium. What I suggest is that you unlock your keyring as requested and then see what keys are being stored in the login keyring for a hint of what might be the cause. For me the solution was then to move my passwords to another keyring and live the login keyring without password.

seth · 2023-11-13 09:14:30

login, enter the password in both dialogs and check "ps aux"

Also wrt @tethys, are you using pam_gkr, https://wiki.archlinux.org/title/GNOME/Keyring#PAM_step ?
Did you see the thread linked in #2 and try to make chromium use the internal keyring?

tethys · 2023-11-13 17:57:17

I didn't change /etc/pam.d/login, I am using automatic unlocking with automatic login (blank password).
I am not using Chromium, Java uses it when I launch one of my applications, but from the thread you linked in #2 Chromium seems to be using "--password-store=basic", because I see the Chromium Safe Storage key in the login keyring, which is now automatically unlocked.

seth · 2023-11-13 20:11:46

If chromium was using the "basic" (built-in) keykring, you'd not see its keys in gnome-keyring
https://wiki.archlinux.org/title/Chromi … word_store

You can use ~/.config/chromium-flags.conf to apply switches regardless of how chromium is invoked.

nicholas · 2023-12-18 15:51:14

I'm also seeing this just now after updating and rebooting. It's been some weeks, so the timeline looks to match here.
I've definitely seen this on Arch in years past, so it's not a "new" bug to me, but I didn't learn what fixed it last time I solved it. I might have just nuked things and started over.

I've googled a few things that don't apply:
- My default keyring is created and has the same password as my login password
- I'm not running any novel or extra clients on login/start-up that I can see via `pstree` or `ps aux`. I've always started with KeepassXC and Guake, which shouldn't use the keyring.

From the wikis: https://wiki.archlinux.org/title/GNOME/Keyring didn't alight on anything too interesting. I'm not using console-based login, I use gdm, and I use firefox so the chromium stuff doesn't totally fit.
From the thread tips here: I don't see any electron or chromium auto-starting and I don't spot a ~/.config/chromium-flags.conf at all, nor do I see any evidence on my system that it's Chrome or Chromium opening it.

Some things that silence the bug:
- (Re)moving ~/.local/share/keyring.
- (Re)moving ~/.config/goa-1.0/accounts.conf

Both of these silences both prompts. Next reboot it won't ask at all, so at least that contains the problem neatly -- it's something goa seems to be doing within the Gnome Keyring area for sure.

I suspect it's goa or evolution which isn't waiting long enough to let the keyring unlock and is running gcr-prompter, but the real question if that's true would be: why does it all of a sudden change its tune from waiting happily and fine to being aggressive and popping a second auth prompt?

Any ideas next to try to pin it down or fix?

Last edited by nicholas (2023-12-18 16:06:11)

seth · 2023-12-19 22:03:29

Wild guess

systemctl --user status gnome-keyring-daemon.service

Try to enable that (as user service) to not rely on the socket activation.

kgtuning · 2023-12-20 00:58:16

Are you connecting via wifi? Maybe check your wifi password isn’t stored encrypted. Click on store password unencrypted.

nicholas · 2023-12-24 20:33:01

seth wrote:

Wild guess
systemctl --user status gnome-keyring-daemon.service
Try to enable that (as user service) to not rely on the socket activation.

This one is on, already, seemingly.

kgtuning wrote:

Are you connecting via wifi? Maybe check your wifi password isn’t stored encrypted. Click on store password unencrypted.

This is a good thought, but probably not it? I don't change that at all between where it mutes and is present and my wifi stays connected all the time. Also, where do you click? I don't see anything in Gnome

seth · 2023-12-24 20:36:13

This one is on, already, seemingly.

What's the actual status output?
(It's likely active because of the socket, but not sure whether it's enabled - cause that would make the socket existence pointless)

nicholas · 2023-12-24 20:38:03

$ systemctl --user disable gnome-keyring-daemon
Disabling 'gnome-keyring-daemon.service', but its triggering units are still active:
gnome-keyring-daemon.socket
$ systemctl --user disable gnome-keyring-daemon.socket
The following unit files have been enabled in global scope. This means
they will still be started automatically after a successful disablement
in user scope:
gnome-keyring-daemon.socket
$ sudo systemctl disable gnome-keyring-daemon
Failed to disable unit: Unit file gnome-keyring-daemon.service does not exist.
$ sudo systemctl disable gnome-keyring-daemon.socket
Failed to disable unit: Unit file gnome-keyring-daemon.socket does not exist.

:squints-loudly:

... so, I feel like we're close to another good piece of info here.
What am I missing that it says it's in the global scope but it's ... not?

nicholas · 2023-12-24 20:38:59

seth wrote:

This one is on, already, seemingly.
What's the actual status output?
(It's likely active because of the socket, but not sure whether it's enabled - cause that would make the socket existence pointless)

Missed this before my last post -- I'm starting to follow. Let me test a bit and get you the output when it's doubled.

seth · 2023-12-24 20:40:04

Nobody asked you to disable any of that.
The point was to
a) check the status of the *service*
b) try to explicitly *en*able the service so it starts unconditionally w/ the session

Edit: crosstalk

Last edited by seth (2023-12-24 20:40:47)

nicholas · 2023-12-24 20:41:55

seth wrote:

Nobody asked you to disable any of that.
The point was to
a) check the status of the *service*
b) try to explicitly *en*able the service so it starts unconditionally w/ the session
Edit: crosstalk

We agree no one asked for that. I'm doing that to learn and understand more about it.

This is what happens before explicitly enabling:

● gnome-keyring-daemon.service - GNOME Keyring daemon
     Loaded: loaded (/usr/lib/systemd/user/gnome-keyring-daemon.service; disabled; preset: enabled)
     Active: active (running) since Sun 2023-12-24 16:40:01 AST; 20s ago
TriggeredBy: ● gnome-keyring-daemon.socket
   Main PID: 679 (gnome-keyring-d)
      Tasks: 6 (limit: 18809)
     Memory: 8.3M (peak: 8.8M)
        CPU: 124ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gnome-keyring-daemon.service
             └─679 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring

Dec 24 16:40:01 localhost.localdomain gnome-keyring-daemon[679]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Dec 24 16:40:01 localhost.localdomain systemd[669]: Started GNOME Keyring daemon.
Dec 24 16:40:02 localhost.localdomain gnome-keyring-daemon[679]: The PKCS#11 component was already initialized
Dec 24 16:40:02 localhost.localdomain gnome-keyring-d[679]: The PKCS#11 component was already initialized
Dec 24 16:40:02 localhost.localdomain gnome-keyring-daemon[679]: The Secret Service was already initialized
Dec 24 16:40:02 localhost.localdomain gnome-keyring-d[679]: The Secret Service was already initialized
Dec 24 16:40:06 localhost.localdomain gnome-keyring-daemon[679]: couldn't prompt for password: The operation was cancelled
Dec 24 16:40:06 localhost.localdomain gnome-keyring-d[679]: couldn't prompt for password: The operation was cancelled
Dec 24 16:40:16 localhost.localdomain gnome-keyring-daemon[679]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Dec 24 16:40:16 localhost.localdomain gnome-keyring-d[679]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk

Last edited by nicholas (2023-12-24 20:42:33)

nicholas · 2023-12-24 20:45:55

$ systemctl --user enable gnome-keyring-daemon.service
produces identical behaviour, but as mentioned, I think we're near something right.

The log-output is identical, and you can see it seems to be aware there's a problem. There definitely were no user-cancelled prompt for passwords, so that's something worth considering.

Last edited by nicholas (2023-12-24 20:46:21)

seth · 2023-12-24 21:04:39

Errr… first off all, please fix you hostname.
"localhost" is not a good choice an eg. NM will likely replace that at some point.
https://wiki.archlinux.org/title/Networ … e_hostname

Not sure whether that alone can explain this.
Reboot, login and then please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

nicholas · 2023-12-24 21:09:33

seth wrote:

Errr… first off all, please fix you hostname.
"localhost" is not a good choice an eg. NM will likely replace that at some point.
https://wiki.archlinux.org/title/Networ … e_hostname
Not sure whether that alone can explain this.
Reboot, login and then please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st

Definitely no concern there. I didn't realize it was such cause for alarm or I would have made the obfuscation clearer, such as obfhost@obsdom.ain -- my hostname is set properly to an FQDN and that shouldn't be the issue. Hasn't ever changed nor did any change coincide with any behaviour there.

I have a bit of work to do so I can't reboot for cleaner logs atm, but I'll prep up a larger journalctl.
It'll be massive -- pastebin? oh neat. 0x0 is cool

Last edited by nicholas (2023-12-24 21:11:33)

seth · 2023-12-24 21:30:20

hostname and time changes are the silent killers

Commonly logs are < 10000 lines and < 1MB in size, but with a sufficiently spammy process, I've downloaded journals of single boots > 100MB
You can redirect it into a file and inspect that first before uploading it, if that's a concern.

nicholas · 2024-01-08 13:19:16

Small hold-up for two reasons (1) holidays and (2) it randomly decided to stop? I thought it best to see if I could drudge up an answer.
Nope!

I took the time to thin out the logs to the first spot where I spotted user activity and massaged a few cosmetic items, but here are the bad and good logs.

I can't quite spy too much "wrong".
I can say that gcr-prompter should not run at all in the good case. It doesn't appear at all in the good log and, yes, I do key in the once, so all is unlocked and well.
System prompter seems to kick that off, but I have no clue why.

seth · 2024-01-08 14:50:12

Dec 24 16:44:11 obfhost.obfuscateddomain.com dbus-daemon[689]: [session uid=1000 pid=689] Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1.0' (uid=1000 pid=679 comm="/usr/bin/gnome-keyring-daemon --foreground --compo")
Dec 24 16:44:11 obfhost.obfuscateddomain.com dbus-daemon[689]: [session uid=1000 pid=689] Successfully activated service 'org.gnome.keyring.SystemPrompter'
Dec 24 16:44:13 obfhost.obfuscateddomain.com gcr-prompter[1142]: Gcr: bus acquired: org.gnome.keyring.SystemPrompter

Difference starts w/ the order of the autostart services gnome-keyring-pkcs11.desktop and gnome-keyring-secrets.desktop which both fail:

Dec 24 16:44:07 obfhost.obfuscateddomain.com gnome-keyring-pkcs11.desktop[763]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Dec 24 16:44:07 obfhost.obfuscateddomain.com systemd[672]: app-gnome-gnome\x2dkeyring\x2dpkcs11-756.scope: PID 756 vanished before we could move it to target cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dkeyring\x2dpkcs11-756.scope', skipping: No such process
Dec 24 16:44:07 obfhost.obfuscateddomain.com systemd[672]: app-gnome-gnome\x2dkeyring\x2dpkcs11-756.scope: No PIDs left to attach to the scope's control group, refusing.
Dec 24 16:44:07 obfhost.obfuscateddomain.com systemd[672]: app-gnome-gnome\x2dkeyring\x2dpkcs11-756.scope: Failed with result 'resources'.
Dec 24 16:44:07 obfhost.obfuscateddomain.com gnome-keyring-secrets.desktop[769]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Dec 24 16:44:07 obfhost.obfuscateddomain.com systemd[672]: app-gnome-gnome\x2dkeyring\x2dsecrets-761.scope: PID 761 vanished before we could move it to target cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dkeyring\x2dsecrets-761.scope', skipping: No such process
Dec 24 16:44:07 obfhost.obfuscateddomain.com systemd[672]: app-gnome-gnome\x2dkeyring\x2dsecrets-761.scope: No PIDs left to attach to the scope's control group, refusing.
Dec 24 16:44:07 obfhost.obfuscateddomain.com systemd[672]: app-gnome-gnome\x2dkeyring\x2dsecrets-761.scope: Failed with result 'resources'.

They're both in /etc/xdg/autostart/ - what if you remove them from there?

nicholas · 2024-01-08 20:52:25

Well, it's working currently with everything in there now:

 $ ls /etc/xdg/autostart/*key*
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop   /etc/xdg/autostart/gnome-keyring-ssh.desktop
/etc/xdg/autostart/gnome-keyring-secrets.desktop

No point removing anything if it's already working (current state), maybe there's a way to break it, instead, back to the faulty mode?

Arch Linux

#1 2023-11-12 06:54:22

[SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#2 2023-11-12 09:24:18

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#3 2023-11-12 17:21:49

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#4 2023-11-12 17:35:52

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#5 2023-11-13 02:30:23

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#6 2023-11-13 07:07:42

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#7 2023-11-13 09:14:30

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#8 2023-11-13 17:57:17

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#9 2023-11-13 20:11:46

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#10 2023-12-18 15:51:14

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#11 2023-12-19 22:03:29

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#12 2023-12-20 00:58:16

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#13 2023-12-24 20:33:01

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#14 2023-12-24 20:36:13

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#15 2023-12-24 20:38:03

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#16 2023-12-24 20:38:59

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#17 2023-12-24 20:40:04

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#18 2023-12-24 20:41:55

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#19 2023-12-24 20:45:55

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#20 2023-12-24 21:04:39

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#21 2023-12-24 21:09:33

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#22 2023-12-24 21:30:20

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#23 2024-01-08 13:19:16

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#24 2024-01-08 14:50:12

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

#25 2024-01-08 20:52:25

Re: [SOLVED] GNOME: Multiple Request to Unlock Gnome Keyring on Logon

Board footer