Importing keyring takes two minutes

[ep12]

Describe the bug
import keyring takes approximately 120 seconds, sometimes less, but on average 120 seconds:

To Reproduce
This is probably not easily reproducable!

Expected behavior
Short import time.

Environment

• OS: Arch Linux
• WM: Qtile

$ pip list | grep keyring
keyring                       21.2.0
$ keyring --list-backends
keyring.backends.chainer.ChainerBackend (priority: -1)
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.kwallet.DBusKeyring (priority: 4.9)

Additional Information

• Related: FYI: under x2go experiences 1-2 min import time #420
• Usually, qtile took less than a second to start. Now it takes approximately two minutes, which is painful considering I can't be productive in those two minutes.
• I did some research and found out that this insane delay is caused by import keyring, because keyring initialises itself when it is imported.
• A (single!) dbus call takes two minutes before it returns (I don't even know if it fails or if it is successfull). But I don't speak dbus so my digging ends here.
• I straced qtile, see here. A recvfrom takes 120 seconds.
• When using pip, the commands I execute do not produce an output for two minutes. That is because pip uses keyring.
• Is it really necessary to perform keyring.core.init_backend when importing keyring?

Questions

• What's wrong with my system?
• How to fix it?

[pawamoy]

Must be coming from kwallet or secret storage as they are the only ones using dbus.

[ep12]

I updated my system and the problem went the way it came. Silently.

[ep12]

Actually, it didn't go away. It came back after logging out and then logging back in. During the session the behaviour stays consistent. Either it imports quickly as it should or it takes two minutes.

[ep12]

When I import keyring I see the following:

Note the (blinking) cursor! I had enough time to open my screenshot program, select the settings (region only screenshot) and then actually screenshot the ouput!
Debugging it with pudb gave this result:

It seems that the secret storage backend takes it's time which is more than I want it to take...

[mitya57]

This is a problem with your D-Bus daemon (e.g. gnome-keyring) — it does not reply in time. Either fix it or set a different backend in the configuration file.

[ep12]

@mitya57 Okay, then how do I fix it? Do you have any clues for me? Commands I can run to figure out what the problem exactly is?

[jaraco]

Is it really necessary to perform keyring.core.init_backend when importing keyring?

Perhaps not, but in your case, it probably wouldn't help much to defer the initialization... because when pip went to check for the credentials, it would then need to initialize and would encounter the issue.

D-Bus daemon does not reply in time.

Can keyring or its client be configured to time out more quickly? Why does it need a 120s timeout? Is that because there may be a user-interactive prompt during that time?

---

As a workaround, keyring now documents techniques to disable keyring. Consider using one of those techniques to bypass the issue.

[takluyver]

Can keyring or its client be configured to time out more quickly? Why does it need a 120s timeout?

This is configured in /usr/share/dbus-1/session.conf. On my system, that contains:

<limit name="service_start_timeout">120000</limit>  

This is the timeout for 'service activation'. When you try to talk to a service that's not currently running, D-Bus can start (activate) a program for it, as defined by files like /usr/share/dbus-1/services/org.freedesktop.secrets.service. The process that starts should connect to D-Bus and claim its name. The timeout defines how long D-Bus waits for it to do this.

I don't think there's any way to override that timeout when talking to D-Bus. But the client (that's us) can give up waiting for a reply sooner than the message bus does - that might explain why the timeout is set so long. I'm working on an overhaul of Jeepney which will include the ability to set a timeout on blocking calls, so keyring or SecretStorage could decide that 5 or 10 seconds is enough.

[mitya57]

This should be fixed by #474.