GNOME Bugzilla – Bug 694238
evolution doesn't wait for keyring to be unlocked
Last modified: 2019-11-12 16:53:23 UTC
I'm running the git master of evo and related libs/programs. I'm on a slackware box, don't run gdm, and use startx to get X and gnome running. Evolution isn't auto-started by gnome-session. When I start evolution I get a pop up asking me to unlock my key ring (unless another program or I manually do so beforehand). However, by the time I get the key ring unlocked, it seems as if evolution has tried accessing various remote accounts, which then seem to hang. While evolution remains usable I end up having to kill it to fix the hung accounts and/or simply shut down. I'm not sure what the problem is, but if the key ring needs to be unlocked, it seems that evolution shouldn't do anything else but waiting (I guess local operations could still be done or those that don't need a password).
Thanks for a bug report. This sounds just like bug #681815. Could you provide a backtrace of evolution in the state of the stuck remote accounts, together with a backtrace of evolution-source-registry, please?
I have the same issue on evolution 3.8.2 Acutually the situation is reliable to trigger by killing the gnome-keyring-daemon in a running gnome-session. Evolution will then start up but never finish any network operation like send&receive. The operations can not be cancelled and evolution has to be killed. steps to reproduce: 1) start a gnome session (unlock login keyring) 2) start evolution (everything is fine) 3) quit evolution 4) $ killall gnome-session-manager 5) evolution (blocks forever on network operations) best regards Roland Lezuo
Your situation is partly about used libraries (or maybe how evolution uses them). Evolution uses libsecret for password prompts, and gcr for accessing gnome-keyring. This is done on evolution-source-registry side. It opens connection to the gnome-keyring on its start and let's it open for the whole lifetime of it. If you kill it, then it doesn't re-establish the connection. If I recall correctly, all the connection details are hidden in the gcr library.
Does one of you still face of this issue, please? I verified and the D-Bus details are not propagated through the libsecret library, thus it's possible this bug should be rather moved there. The best if you could try with at least 3.12.x of evolution.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!