Launchpad has imported 12 comments from the remote bug at https://bugs.kde.org/show_bug.cgi?id=254198.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-10-14T21:55:30+00:00 Andrei-mihaila wrote: Version: unspecified (using KDE 4.5.2) OS: Linux This happens most of the times at system startup when both say... KMail/Kontact and Pidgin with the KWallet plugin (http://kde- apps.org/content/show.php/Libpurple+KWallet+Plugin?content=127658 ) try to open the default wallet. If Pidgin goes first everything is ok, if KMail goes first and Pidgin second kwalletd seems to lock. In a few seconds the Pidgin plugin gets a timeout and KMail hangs. I have to restart kwalletd in order for it to work (only tried by killing it and starting it again). Reproducible: Always Steps to Reproduce: I've tried to make it as easy as possible to reproduce using qdbus. Assuming there is a wallet called kdewallet the next 2 lines should make kwalletd lock. qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet 1 'Test1' & qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet 2 'Test2' & Actual Results: The response after a few seconds is: Error: org.freedesktop.DBus.Error.NoReply Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Error: org.freedesktop.DBus.Error.NoReply Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. And after that any request for kwalletd hangs if via the C++ interface or gets timed-out if via D-BUS. Expected Results: The D-BUS request should be handled correctly - that is queued. After the user answers the first request the second should be shown. If the user takes too long to respond (enter password/click Allow) and you can't find another solution but to give it a timeout - that should be transparent so that the application would know it needs to try and connect again. I had a look at the kwalletd code (it was early this spring, maybe things changed since then) and couldn't find anything obviously wrong... I'm thinking it could be the generated D-Bus wrapper. Thanks in advance for solving this (or at least for reading my report). Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/0 ------------------------------------------------------------------------ On 2011-02-01T21:11:51+00:00 Andrei-mihaila wrote: Still there in KDE versions 4.5.3 to 4.6. I wish I could find some time to hunt the problem myself ... Thanks for reading anyway. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/1 ------------------------------------------------------------------------ On 2011-03-11T19:16:00+00:00 Jfergem wrote: I stumbled over this bug, too, with Chromium and Kopete locking up kwalletd. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/2 ------------------------------------------------------------------------ On 2011-06-16T19:04:01+00:00 Andrei-mihaila wrote: Still there in KDE 4.6.4... Additionally, found that after kwalletd is locked the wallet manager shows it as being empty, although it is not (after restarting the daemon all my passwords were there). Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/3 ------------------------------------------------------------------------ On 2011-07-29T13:30:23+00:00 Daniel-pena-arteaga wrote: I also found this problem with KDE SC 4.6.5 in Archlinux. For example, Akonadi IMAP resources will just hang there without being updated, no passwords shown in kwalletmanager, no way to create new wallets, chromium unable to fill password fields if just started, ... If I then kill kwalletd, suddenly the dialogs asking for all password appear, just like without using kwallet, and everything seems to be fixed until next kwallet hang. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/4 ------------------------------------------------------------------------ On 2011-09-17T21:32:06+00:00 Zersaa wrote: Same problem with Kopete and Chromium, KDE 4.7.1 Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/5 ------------------------------------------------------------------------ On 2011-10-20T20:24:48+00:00 Bugs-phlogi wrote: I can confirm this bug, also running arch linux. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/9 ------------------------------------------------------------------------ On 2011-10-20T20:25:24+00:00 Bugs-phlogi wrote: *** This bug has been confirmed by popular vote. *** Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/10 ------------------------------------------------------------------------ On 2011-10-25T07:03:59+00:00 Tais-hansen wrote: I can confirm this behavior. I use keychain with ksshaskpass in my bashrc, so I have to -KILL kwalletd every single time I log in to KDE and want to use the console. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/11 ------------------------------------------------------------------------ On 2011-12-23T07:27:02+00:00 Gábor Gludovátz wrote: Same problem with KMess and KRDC. KDE 4.7.3. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/12 ------------------------------------------------------------------------ On 2012-04-03T13:06:07+00:00 Sven-Hendrik Haase wrote: Same problem in KDE 4.8.1. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/14 ------------------------------------------------------------------------ On 2012-07-28T04:23:58+00:00 Cognifloyd wrote: This looks like an old bug: #123583 I have ksshaskpass and google-chrome cause some kind of race condition hanging ksshaskpass, and kwalletd. Google-chrome continues like nothing happened, except that it doesn't have any saved passwords (as expected with this issue). I'm in gentoo with kde 4.8.3 with a 64 bit kernel. Reply at: https://bugs.launchpad.net/kde-runtime/+bug/874199/comments/15 -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to kde-runtime in Ubuntu. https://bugs.launchpad.net/bugs/874199 Title: ksshaskpass hangs forever when run from keychain during KDE login To manage notifications about this bug go to: https://bugs.launchpad.net/kde-runtime/+bug/874199/+subscriptions -- kubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
