Bug 166376

The kwalletd starts automatically as soon as an application requests a password from it, so you "disable" it by not launching any applications that do that on session start.
Do you maybe have any debug output so we could trace the problem (maybe ~/.xsession-errors)?

Created attachment 26082 [details]
startx.log

I really don't understand what application is invoking kwalletd at startup...
I attach a log obtained by 'sh -x startx' , there's some stuff there...

It's funny how things goes sometime... I just have a massive update from my distro with a new heimdal package included, that broke my kio_http compiled from source. 
As I see in the log I attached before, kio_http is invoking kwalletd and crash. Now that kio_http is broken the bug desappears and kde4 boot just fine.

I don't know if this is a bug or something in my user configuration. Could it be a preload of konq? Anyway I disabled it from konq settings.
Now I have to rebuild kdelibs..

I had a quick look on the logs and it all seems pretty strange. Apparently quite some applications on the D-Bus don't respond (eg. kpasswdserver, kwalletd, Nepomuk, ... some of them unique applications). So after all it might be a problem related to your dbus server.

Resetting .kde4/ solved the problem, after a lot of use something was messed there. Resetting kdedir is not funny but sometimes after heavy trunk usage, I have to do that..

I would like to reopen this , because is somewhat annoying. As said, after kde4 boot and after that the desktop shell is shown, activities on kde are freezed for some seconds until the dialog window of kwallet appears for password request.
None apps seems to request kwallet usage at that point , it seems a kded kwallet module issue. Using kde4 trunk
Thanks

Could you please check if the errors/logs still show the same you posted in c#2? Please provide as much information as possible because without it I have no chance to help you as it works fine for me.

Here it's a startx log of a kwallet freeze.
This were my steps:
- in the previous session I start kmail ( and kwallet popup for his stuff)
- I close the session leaving kmail and kwallet in the systray
- restart with freeze

please note that I set to not restore the previous session at kde startup

can't attach log.. see here please
http://pastebin.ca/1242483

kwallet keeps starting at the begin of an empty session..
why this behaviour? nobody need it and it's annoying , can someone take care?

What do you mean by "empty session"? kwalletd only starts if it's requested by an application. Your log indicates that on logging in kio_http is launched which in turn launches kpasswdserver which in turn starts kwalletd to check for authentication information on a site that's opened.

Forgot something: If you don't want to use kwallet you can always disable it in systemsettings.

I know I can disable it , but I would like to use it..
empty session is meant as new session at startup, sorry.
If so I don't know why kio_http keep tring to open that stuff that apparently I don't need. I'll try to catch which process at login open that connection, may be some plasmoid. But again there's something to fix in this behaviour and maybe the bug it's not kwallet related.

Hi!

had a similar problem on my machine. it was unresponsive for a certain period of time near the end of the login process, before kded was asking for permission to open a wallet. this was happening not every time but especially often during a re-login. supplying a password for (my only) wallet (of course) did only lead to another prompt like the first one.

however i could work around the issue by disabling the rssnow plasmoid. so, i'm wondering if you guys have rssnow enabled?

markus

It's possible that RSSNOW is trying to open the wallet. However it should only do so if you're reading a stream you need to supply a password for. You could of course try not opening the wallet and see what happens / which plasmoid fails.

Created attachment 31178 [details]
xsession-errors showing the strange behavior

I can confirm this bug. This also happens for me (KDE4.2 gentoo), clean install starting with empty .kde4. Not sure whether it happened at the first login, but it is 100% reproducible now. I attach my .xsession-errors below. The symptoms are precisely the same, but I am not using RSSNOW. The only plasmoid accessing the net should be the "LCD Weather Station", but it works just fine whether I enter a password for the wallet or not. I do not know who/what starts the kio_http(5578), nor what the many programs with empty names are that kdeinit4 prepares to launch. Also the <unknown program name> processes (5566 and 5569) are gone by the time I can get to a usable shell. No idea why they can't communicate with anything, although things seem to launch just fine. The kwalletd password dialog says it has been requested by "KDE Daemon". But why? Any ideas on how to debug this?

OK, on my setup the culprit is clearly the LCD Weather Station plasmoid. Have removed it from the panel, closed the session, started a new session and all the strange stuff in .xsession-errors is gone. The wallet is not openend and everything works normally. I will now try to re-add it to the panel and see if I can reproduce the bug. Will report back shortly.

Created attachment 31184 [details]
xsession-errors with LCD weather plasmoid removed

Wow, this is getting weirder by the minute. I added the plasmoid back (within the running session) and there were no unusual additions to .xsession-errors. Closed the session, started a new session, still worked. Then I rebooted and, voila, the problem is back again. So, it looks like this has some connection to library loading. At least that is the only thing I can think of what would be different in these two situations, some library being already loaded or not. How can we find out where this is coming from? Do you other guys also use  the LCD Weather Station or is this connected to plasma itself?

The last comment on this ticket is over two years old. Is this still an issue in the current version of KDE, v4.7 ?

Hi again!

@ Dawit Alemayehu - comment 22:

Yes, every now and then my KDE (4.8.0) desktop (on gentoo linux) experiences a stall right after the splash has faded out. Half a minute or so later, the desktop becomes responsive, however some KDE apps like kontact (kmail), konqueror when started cause the desktop to freeze again. Also some systray applets like kwallet, kmix and some more are missing. This does not happen every time.

I made the following observations over time:

1. Disabling Nepomuk in Systemsettings seems to resolve the issue so far, but I've done this only recently so I might be wrong.

2. On a "stalled" startup .xsession-errors contains messages like the following often repeated serveral times:

  "Cannot connect to agent instance with identifier 'akonadi_imap_resource_4', error message: 'Could not get owner of name 'org.freedesktop.Akonadi.Resource.akonadi_imap_resource_4': no such name'"

  korgac(4856)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed:  "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."

  "D-Bus communication 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.'"


On a startup without delay there are some dbus related (and other) messages as well but I've not seen any of the above. 

Of course configuration was not "intentionally" changed between these tries.

Thank you!

Markus

after upgrading to 4.8 i got a lot of hangs and errors like this:

KSystemTimeZones: ktimezoned initialize() D-Bus call failed:  "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.

lamarque pointed out in http://lamarque-lvs.blogspot.com/2012/03/desktop-freezes-in-48x.html that a blocked/sleeping/waiting kded could be the cause. and indeed kded did not response in my lockups (see http://forums.gentoo.org/viewtopic-t-915580.html).

After a long struggle found out the kmixd module of kded causing most (but not all) of my stalls.

markus

I can confirm what #24 writes - kmixd is making kded stall sometimes. Investigating further.  I have a bunch of zombie kdeds too.

Does removing ".pulse" help?

Hi Christoph, 

I have the same bug  (Gentoo x86_64, KDE 4.9.1), and yes, removing  ~/.pulse solves it. But as this contains the hardware list, this is not really a permanent solution. 

I hope it helps you finding the cause though. Please poke me if there is further information I can provide to track this down. 

Kind regards, 

Christian

I would advise you disable kmixd from the KDE Systemsettings "kded module" - I don't know the correct english name, bit it is probably "KDE Services".
It has no effect unless you have an appplication/Plasmoid that uses it. The KMix GUI application does not use it.

(In reply to comment #28)
> I would advise you disable kmixd from the KDE Systemsettings "kded module" -
> I don't know the correct english name, bit it is probably "KDE Services".
> It has no effect unless you have an appplication/Plasmoid that uses it. The
> KMix GUI application does not use it.

Alright, thank you very much, I try that and disable the "delete-pulse-before-login"-thing I currently use. I'll let you know if it doesn't work as intended. 

Of course a fix in that module would still be appreciated, especially probably by people using veromix and such. 

Kind regards

Merging this ticket with bug 317926. Should be solved in KDE4.11. Please follow bug 317926.

*** This bug has been marked as a duplicate of bug 317926 ***