Bugzilla – Bug 271307
Kickoff freezes KDE-Desktop when NFS is unresponsive
Last modified: 2008-07-30 13:38:53 UTC
I sometimes experience, that clicking the SUSE icon in KDE/Kicker (Kickoff modus) freezes my desktop. The chameleon icon changes it's color to orange, but nothing happens... the menu won't open. I can't click icons on the desktop anymore, only existing apps seem to be left working. Killing the session using Ctrl+Alt+Backspace and logging in again won't help, as soon as I click the Kickoff icon the desktop freezes again. However, right clicking the Kickoff icon and switching to the old KDE menu style is possible and won't freeze the desktop. Clicking the old KDE menu button brings up the menu and everything works fine, no freezes. Switching back to Kickoff mode and left clicking the menu icon freezes the desktop immediately. So this is definitely a Kickoff related problem. Until yesterday I didn't know the reason for this behavior, why it only sometimes happen and how to reproduce it. Well, yesterday I realized, that it happens when I remove the network cable from my notebook and click the Kickoff icon afterwards. As long as I have no network connection, the desktop is frozen. But if I re-plug-in the network cable, the desktop recovers ater about 10 - 20 seconds and the menu appears and everything is working fine again. Here is the scenario how to reproduce it: - running KDE session with network connection - remove network cable and take the notebook with me to the couch, kitchen, ... whatever - left clicking the Kickoff menu icon to start some application (e.g. OpenOffice) freezes the desktop - I go back to my desk and plug-in the network cable, after 10 - 20 seconds the menu opens and KDE is usable again May it be, that Kickoff tries to access some NFS shares before the menu shows up? I have some NFS shares mounted (non of them is essential to the system or KDE) and they are not unmounted automatically when you just remove the network cable, so my first guess would be that this is causing Kickoff to hang!? Well, it seems my guess was good. If I do a 'rcnfs stop' before removing the network cable, Kickoff won't freeze when I click the menu icon. Of course this is no solution, because users without root rights can't shutdown the NFS client before they remove the network cable to move their notebook somewhere else. So I suggest to revisit the Kickoff code and consider that disconnected NFS shares can freeze Kickoff/Kicker/Desktop.
This is also happening when I switch from Wireless to a Wired network with my laptop. I have different static assigned IP addresses for each connection. Doing a packet trace while switching I notice that there is some NFS traffic at the point of the switch. I thought it might be something to do with the Recent Documents list and even after emptying this there is still some NFS traffic as the menu is about to be opened. I will try Jorg's work around to see if it works in my situation. Cheers Jim
Just back from experimenting with the "rcnfs stop" command. If I run the command after the menu has hung in my situation, I get a NFS Share is busy message and the menu stays hung. However if I run the command before doing the switch the menu behaves OK. but of course I have lost access to the shares. Note that the NFS share in my case has _nothing_ to do with my home directory, or any other system directory. It is just providing access to a shared data area. Jim
Also occures on 10.3 Beta2. Seems not a KDE/Kickoff (sysinfo:/ too) specific bug but a base system/network bug: - boot in init3 - mount nfs - stop nfsserver - ls /dir/nfs freezes If you don't mind I will change product and component - 10.3 is top priority right now.
Reassigning to Christoph Thiel (as asked to bugs with high priority)
That's a normal misfeature of NFS. The only bug is that KDE polls NFS more often than it might be good. So please don't hijack bugs.
*** This bug has been marked as a duplicate of bug 219929 ***