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.
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).
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' & KWallet. open kdewallet 2 'Test2' &
qdbus org.kde.kwalletd /modules/kwalletd org.kde.
Actual Results:
The response after a few seconds is:
Error: org.freedesktop .DBus.Error. NoReply .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
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).