[karmic] plasma panel freezes for a few seconds when opening a usb drive

[Jithin Emmanuel]

Binary package hint: plasma-widgets-workspace

I have a 320 GB USB drive which has about 200 GB data.
When I mount my drive, either clicking on Device Notifier applet or by dolphin Places, plasma panel freezes for a few seconds, ie until the drive is opened in dolphin it freezes the panel and everything goes back to normal once dolphin opens the drive.

Its the same if I mount manually using mount command. Plasma freezes for a few seconds, during which
1. system tray works.
2. no other applets in plasma works - eg, desktop switcher, task manager, notifiactions
3. alt-tab switching of applications work.

I believe its not related to device notifier.
I removed Device Notifier. Mounted from konsole. After 2 seconds it freezes the plasma panel. I dont even have any dolphin or anything running. But the device is properly mounted. I opened a movie in the drive with mplayer when the plasma panel was in a frozen state.

So my guess some process related to plasma is reading something from the device which freezes it.

[Exabyte-g (exabyte-g)]

Version: (using KDE 4.2.0)
Compiler: GCC 4.3.1
OS: Linux
Installed from: Gentoo Packages

How I manage to reproduce this on my machine: Use kickoff menu, have a NFS mount (in my case, mounted before KDE started), unplug the network cable and wait. Plasma hangs after a few seconds-minutes and comes back to life when I plug my network cable back. Also, adding the kickoff plugin when the network cable is unplugged results in a immediate crash.

I ran strace on plasma and the result when the hang appears is this:

lstat("/dev/md1", {st_mode=S_IFBLK|0640, st_rdev=makedev(9, 1), ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/dev/md2", {st_mode=S_IFBLK|0640, st_rdev=makedev(9, 2), ...}) = 0
lstat("/volatile", {st_mode=S_IFDIR|0755, st_size=56, ...}) = 0
lstat("/dev/md0", {st_mode=S_IFBLK|0640, st_rdev=makedev(9, 0), ...}) = 0
lstat("/boot", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("firebird:/home/ftp/pub", 0x7fffda66dec0) = -1 ENOENT (No such file or directory)
lstat("/home/ftp/pub", <unfinished ...>

So it is obviosly trying to lstat all devices *and* mountpoints. This leads to hangs, and I believe stating the nfs path is incorrect behaviour either way.

Of course, such hangs in apps are expected (and wanted) when nfs goes away, but having the whole plasma hang is quite an unpleasant side effect, and likely possible to fix. :)

[Francis-mestdagh (francis-mestdagh)]

*** Bug 185552 has been marked as a duplicate of this bug. ***

[Jirik-0 (jirik-0)]

I am confirming this. It is really annoying. This should not happen. KDE components should not have dependency on components like NFS.

Can someone please fix it urgently.

Environment:
Debian Unstable, KDE 4.2.2

Problem:
When NFS mounted and unplug cable plasma process reports "disk sleep". Any part of Plasma is not responsive.

[Arkadi-shishlov (arkadi-shishlov)]

Same with CIFS mounts on Fedora:
Plasma freezes when network mount is unavailable
https://bugzilla.redhat.com/show_bug.cgi?id=491211

[Dario Andres (andresbajotierra)]

Have you tried removing the Kickoff menu and reproduce the NFS disconnection to test if it is indeed related to Kickoff or to another component? (I'm also thinking about the Device Manager; or the base lib for this: Solid)
Thanks

[Jirik-0 (jirik-0)]

If you umount the NFS export (umount /mnt/data -l) then everything becomes responsive again in about 1 minute.

[Exabyte-g (exabyte-g)]

(In reply to comment #4)
> Have you tried removing the Kickoff menu and reproduce the NFS disconnection to
> test if it is indeed related to Kickoff or to another component? (I'm also
> thinking about the Device Manager; or the base lib for this: Solid)
> Thanks

Yes, when there is no Kickoff menu the NFS disconnection doesn't lead to Plasma hang. There was some strange behaviour in some gadgets and apps, but I can't recall what it was, but the behaviour described in the report happens due to Kickoff. I don't claim that the root cause is Kickoff's code, though. But the "Computer" section in the menu is what most probably triggers it.

To be clear what I mean by "some strange behaviour" above: Trying to open a folder containing a disconnected NFS mount with Dolphin is an example. Dolphin is responsive, but huge part of the files and folders in the folder simply aren't shown until NFS comes back.

[Dario Andres (andresbajotierra)]

Thanks for the tests.

[Michal Witkowski (neuro-o2)]

Yes i can confirm the same behaviour with Arch Linux KDE 4.2.4.

I've got two NFS shares mounted upon connecting to my home wireless server. Whenever I turn my wifi-switch off, plasma hangs. This doesn't happen when NFS shares are unmounted.

I've also tested the case with a cable connection. Same story: when NFS shares are mounted, unplugging the cable causes plasma to freeze. With no NFS shares, everything works alright.

[Jithin Emmanuel (jithin1987)]

One side effect of this bug is any notifications which appear during that time,
like a chat message received in kopete during this time stays in notification
area itself.

[Jonathan Thomas (echidnaman)]

Does this also freeze the mouse and other applications, or is it just Plasma that freezes?

[Jithin Emmanuel (jithin1987)]

Only for plasma panel. Rest all works. Even system tray except notifications.

[Dario Andres (andresbajotierra)]

*** Bug 202242 has been marked as a duplicate of this bug. ***

[aseigo (aseigo)]

*** Bug 201897 has been marked as a duplicate of this bug. ***

[Dario Andres (andresbajotierra)]

*** Bug 202271 has been marked as a duplicate of this bug. ***

[Michal Witkowski (neuro-o2)]

The bug is very much alive in KDE 4.3.0.

In can be reproduces exactly as before (see comment #8).

[Jithin Emmanuel (jithin1987)]

upstream bug
https://bugs.kde.org/show_bug.cgi?id=184062

[Jithin Emmanuel (jithin1987)]

Why is this bug still unconfirmed? I am having this issue every time I plug my usb drive.

[giaso (giaso)]

I can confirm the bug is still alive in KDE 4.3.1 on kubuntu jaunty packages. I can reproduce it by the following steps (using kickoff as launcher):
- Login as user A
- Let network manager put up wireless connection and mount nfs share
- Log out
- Log in as user B
- Plasma hangs on splash

[Alexander Inglessi (inglessi)]

*** This bug has been confirmed by popular vote. ***

[Jithin Emmanuel (jithin1987)]

The issue I had I think is kubuntu specific one. I moved to arch linux. Now its plasma is not freezing on mounting usb drive.

[Rich Johnson (nixternal)]

Confirming due to upstream, even though most of the comments relate to NFS, it also occurs with some pluggable devices, in this case a large usb drive. My 120GB I don't notice this, but my 1TB I do.

[Jithin Emmanuel (jithin1987)]

I am not sure if the bug is with kde. I moved to arch linux there I am not experiencing this problem with my same 320 gb disk.

[Rich Johnson (nixternal)]

Funny you should say this, as my 1TB drives takes a few seconds as well in GNOME. If I remember correctly, recently there were some issues with USB. If I do this on my desktop which is a fresh install, I can't reproduce this, however my laptop which is a mess from hacking on it, probably isn't the best thing to try and reproduce on.

I will research a bit more and see if I can come up with anything. Thanks!

[Jithin Emmanuel (jithin1987)]

I can confirm that this issue with usb drive freezing plasma is because of 2.6.31 kernel. Noticed when 2.6.31 kernel was available in arch. Downgrading to 2.6.30 kernel fixed the issue.

Is the problem with kde or kernel. Can any kde devs confirm?

[Pcgscrap (pcgscrap)]

This bug still exists in kdebase-workspace-4.3.1-9.fc10.i386 and is simple to reproduce, see following link below for steps. And https://bugzilla.redhat.com/show_bug.cgi?id=529373 shows another older report of same problem linked to it.

[Sebastian Sauer (mail-dipe)]

Created attachment 37728
cd ~/path/to/source/of/kdebase && patch -p0<bug184062.diff && make install

Is the hang gone with the attached patch bug184062.diff? Best way to test that is to have only the kickoff applet running and no other applet.

Background; KDirWatch blocks :-/

[Sebastian Sauer (mail-dipe)]

Created attachment 37729
updated patch

[Jithin Emmanuel (jithin1987)]

Without the patch and kernel 2.6.32-rc6 fixes the issue for me.

[Asraniel (asraniel)]

what is the status of this bug? what about the patch? can we get this fixed for 4.4 final? thank you

(if the submitter of the patch does not have an svn account, consider uploading the patch to reviewboard.kde.org)

[Jirik-0 (jirik-0)]

Can anyone increase this as the HIGH priority to fix.
All my notebooks have got same issue. This is really annoying issue.

More annoying is that nobody is trying to fix it. This issue goes from 4.1 release.

[Asraniel (asraniel)]

problem is that there is no real maintainer for kickoff currently.. but i increased the priority

[Asraniel (asraniel)]

i forgot to mention, please test the proposed patch, i can commit it if needed, but somebody has to test it.

[Asraniel (asraniel)]

if anybody cares about this patch, it has to be tested and submitted to the right people. please contact the plasma developers in IRC or on the plasma-devel mailing list. thank you

[Sebastian Kügler (sebasje)]

The patch looks wrong, porting from KDirWatch to QFileSystemWatcher is the wrong thing to do. KDirWatcher should simply not block, and that's the real cause of the problem.

Now the question is "where does it block (when it shouldn't)?". Anyone who can reproduce the problem, please attach a debugger to your Plasma and tell us where it blocks. Those that have reported crashers, please supply a backtrace.

The s/KDirWatch/QFileSystemWatcher workaround is unlikely to go in like this.

[BRULE Herman (alpha-one-x86)]

I thinks I have the same bug here.

[aseigo (aseigo)]

*** Bug 181323 has been marked as a duplicate of this bug. ***

[Asraniel (asraniel)]

Any work beeing done on this bug? having a patch (even if it is wrong) at least helps to identify the problem.

[David Faure (faure)]

Well, the backtrace requested in comment #27 would be much more useful than a bad patch (we use KDirWatch everywhere else in KDE, so the problem would just move to somewhere else).

But this is really odd, the patch is about the RecentDocuments directory which is something like $KDEHOME/share/apps/RecentDocuments/, and which contains only desktop files, this should be totally unrelated to NFS mounts.

[Harald Sitter (apachelogger)]

Closing in favor of upstream report. Please refer there for updates on the issue.

[Bugs-kde-org3 (bugs-kde-org3)]

I'm not sure if this also belongs here:

When I have a cifs share mounted and tell KDE to poweroff, it also hangs like 2 minutes during shut down until it finally times out and turns off. For some reasons the shares aren't properly dismounted hence the timeout somewhere.

[Sebastian 'polrus' Tur (dpbasti)]

still exists in kde 4.9.5

having no additional apps open, just desktop widgets (weather+eth traffic + temperature monitor)
when i remove the ethernet cable the whole desktop freezes,

i tried to disable network in networkmanager plasmoid before removing the cable -

the result is the same

ctrl-alt-backspace does not solve the problem

[Dennisgrunert (dennisgrunert)]

Christoph Feck changed the version from 4.8.4 to 4.9.5. But shouldn't it be the lowest version number where this bug can be found, to find regression: Bugs usually don't disappear with newer versions.

[BRULE Herman (alpha-one-x86)]

I use Qt5SystemInfo for mount point manipulation (change, read), it's not the solution here?

[Sebastian Kügler (sebasje)]

@Dennis: The logic is the other way round, the first question is usually: is this bug still valid.

[Dennisgrunert (dennisgrunert)]

(In reply to comment #68)
> @Dennis: The logic is the other way round, the first question is usually: is
> this bug still valid.

Sorry, I though so, because I did set the field to the newest version myself one time and received this reply: https://bugs.freedesktop.org/show_bug.cgi?id=52179#c5

No I'm confused what helps the dev's the most to narrow it down. But this seems to be too much off-topic for a this long bug. I'm sorry about that.

[Vincent-rubiolo (vincent-rubiolo)]

Also getting this bug (Ubutu 12.04 - KDE 4.8.5). I usually get by using the following:
1. Lazy unmount of the problematic mount point (sudo umount -l /mnt/mountpoint).
2. Restart plasma : killall plasma-desktop && plasma-desktop That allows the panel to unfreeze. Unfortunately, it also pollutes the notification area with lots of spurious notification entries, resulting in a smaller (width-speaking) taskbar/paenl. I have to manually hide those to get back to the actual panel width (see screenshot).

Is there something we can do to help as users (getting backtraces, etc) so that this problem is fixed?

[Vincent-rubiolo (vincent-rubiolo)]

Created attachment 77609
Vincent's system tray spurious notifications

[BRULE Herman (alpha-one-x86)]

I use solution to prevent this in my application: I use Qt5 Qt System Information module (tiers modules). That's work by event and prevent that's. But to be compatible with Qt4, I suggest thread usage with queued connexion.

[Vincent-rubiolo (vincent-rubiolo)]

(In reply to comment #70)
> Also getting this bug (Ubutu 12.04 - KDE 4.8.5). I usually get by using the
> following:
> 1. Lazy unmount of the problematic mount point (sudo umount -l
> /mnt/mountpoint).
> 2. Restart plasma : killall plasma-desktop && plasma-desktop That allows the
> panel to unfreeze. Unfortunately, it also pollutes the notification area
> with lots of spurious notification entries, resulting in a smaller
> (width-speaking) taskbar/paenl. I have to manually hide those to get back to
> the actual panel width (see screenshot).
>
> Is there something we can do to help as users (getting backtraces, etc) so
> that this problem is fixed?

Forgot to mention that you'll also need to restart krunner in this case, otherwise you'll also lose handling of some keyboard shortcuts (esp Ctl-Alt-L to lock your desktop).

[Marcin Janowski (janowski-m)]

Still exists in kde 4.10

If i disconnect my ethernet cabel and connect to new router (i want install new router, so this havent internet), plasma hang.
This same if in university block me internet - i have routing only to AP and plasma zombie.

How can i help and debug this?

[aseigo (aseigo)]

It has been noted several times in this bug report what is needed to improve the situation: back traces of the frozen application.

Phillip did so in comment #50 and that resulted in a fix. That was not the only problem leading to the same symptom, though, and we need backtraces from those situations so we know what we're looking for.

[Marcin Janowski (janowski-m)]

Created attachment 77646
Debug

Ok, i try to make debug with gdb, please tell me if it is make good.

[Andrew-myers (andrew-myers)]

Already did a bug report under duplicate bug Bug 290855 with a gdb debug report

[Sebastian 'polrus' Tur (dpbasti)]

probably the same or similar problem existr if I'm conected via openVPN to ym company network and have some CIF mounts there. When i disconnect from openVPN plasma also freezes.
I'm not sure if it's thee same bug or just similar one?

[Marcin Janowski (janowski-m)]

When i have network access and i have routing to internet, all work good. But when unexpectedly i have lost routing to internet (i have connect to AP), plasma hangs out. Next, when routing go back, plasma hangs off (work good).

BT: #0 0x00007f5962007303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007f5955c0cd84 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f5955c0cea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f595ec01c26 in QEventDispatcherGlib::processEvents (this=0x215cad0, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#4 0x00007f595e01fc1e in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#5 0x00007f595ebd22ef in QEventLoop::processEvents (this=this@entry=0x7fff982183a0, flags=...) at kernel/qeventloop.cpp:149
#6 0x00007f595ebd2578 in QEventLoop::exec (this=0x7fff982183a0, flags=...) at kernel/qeventloop.cpp:204
#7 0x00007f595ebd7738 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187
#8 0x00007f596231b1b1 in kdemain (argc=1, argv=0x7fff98218698) at ../../../../plasma/desktop/shell/main.cpp:126
#9 0x00007f5961f4076d in __libc_start_main (main=0x4006a0 <main(int, char**)>, argc=1, ubp_av=0x7fff98218698, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fff98218688) at libc-start.c:226
#10 0x00000000004006d1 in _start ()

[Jree2kx (jree2kx)]

This is definitely still an issue in 4.10. I can reproduce every time by plugging in my ethernet and switching off wifi to transfer large files to my NAS. It only locks up Dolphin. If I umount my CIFS shares everything then returns to normal. Quite irritating to say the least.

Arch x86_64
KDE 4.10.2
kernel 3.8.8

[Jree2kx (jree2kx)]

Update to my previous comment. I finally switched over everything to NFS and the issue still persists.

[Ettore Atalan (atalanttore)]

kdialog is also freezing when this issue takes place. Maybe it has the same reason?

[Jree2kx (jree2kx)]

Is there any chance this will be fixed in 4.11? This is big bug imo. You shouldn't have to restart your computer after switching interfaces.

[DA (adawit)]

*** Bug 274674 has been marked as a duplicate of this bug. ***

[Ralf Habacker (ralf-habacker)]

Created attachment 82265
plasma-desktop backtrace

same issue here with plasma-desktop on opensuse 12.2 x86_64, kde 4.11.1 and pam_mounted cifs mounts

[Ralf Habacker (ralf-habacker)]

bug 316655 seems to have the same reason.

[Laurent-9 (laurent-9)]

Hi, I got this bug since several months.
I read on different bug reports that the freeze was due to the fact that some users where using kernel cifs mount and thus it was more a kernel bug.
(you can find a lot related, "freeze smb cifs")
So I switched to smbnetfs mount that is a fuse mount of the samba share.

Once I come back to home and computer wake up from sleep, fuse mount does not see anymore the files, still kde desktop is completely frozen until I do fusermount -u -z /media/smb

Now I still don't understand why it freeze since kde shouldn't knew that I got a mount now...
Perhaps it scans all fuse mount?

The kde desktop freeze when either:
    - I open dolphin
    - Open kate and click on open a file.
    - From firefox, select a file -> (it open a kde file dialog) all frozen.

Under debian/testing, KDE 4.10.5 (got also that on kde 4.9)

[Software-n (software-n)]

I confirm freezes of the whole panel after waking up from standby with unavailable nfs mounts in the background. The freeze goes away when the nfs target becomes available again. With xfce I did not have this problem.
Without knowing the technical kde internal details I think that network mounts should be detected by kde and be marked as unreliable, i.e., nothing should depend on them to prevent such execution blockings.

I am running arch linux with the following packages:
linux 3.12.8-1
extra/kdebase-lib 4.12.1-1
extra/kdebase-plasma 4.12.1-1
extra/kdebase-runtime 4.12.1-2
extra/kdebase-workspace 4.11.5-1
Btw: Several nfs directories are mounted using the bg flag.

I guess one workaround for users having this problem is to mount network shares via autofs. However, the kde core gui parts such as the panel should definitely not freeze when, e.g., a connected network attached storage is offline.

[Dennisgrunert (dennisgrunert)]

@Moritz: Please read comment 75 if you want to help. Thank you.

[JW (jason-wallace)]

I'm having the same apparent problem, where different applications (Chrome, Kontact, Dolphin, etc) will freeze for minutes on end. I ran strace on a hanging process (Chrome in this case). The output from ~30 seconds is below:

write(11, "!", 1) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 1 ([{fd=10, revents=POLLIN}])
read(10, "!", 2) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 0 (Timeout)
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 818) = 0 (Timeout)
write(44, "\0", 1) = 1
futex(0x7fd4837050b0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fd489a6ca48, FUTEX_WAKE_PRIVATE, 1) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 0 (Timeout)
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 8888) = 1 ([{fd=10, revents=POLLIN}])
read(10, "!", 2) = 1
write(11, "!", 1) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 1 ([{fd=10, revents=POLLIN}])
read(10, "!", 2) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 0 (Timeout)
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 8886) = 0 (Timeout)
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 0 (Timeout)
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 284) = 0 (Timeout)
write(11, "!", 1) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 1 ([{fd=10, revents=POLLIN}])
read(10, "!", 2) = 1
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 0) = 0 (Timeout)
recvfrom(8, 0x7fd483747074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 3, 823) = 0 (Timeout)
write(44...

[Software-n (software-n)]

Created attachment 87734
strace of hanging plasma with recent kde

created by using kde 4.13.2 and the command
strace -tt plasma-desktop

hanging: all entries with time 07:12:xy
resuming (correlated with the re-availability of the nfs master): entries with time 07:23:xz

[Marcin Janowski (janowski-m)]

Workaround for me: remove from plaismoids gmail-plaismoid . Now i havent problem with hangs.

Qt: 4.8.6
KDE: 4.13.2
kde4-config: 1.0

[Bugs4-kde-org (bugs4-kde-org)]

on shout down the same happens when you mount stuff over openvpn... because first openvpn gets closed before it tries to unmount networked drives. On Kubuntu openvpn also comes with down-root plugin.

So I just enhanced my ovpn config with this:

plugin /usr/lib/openvpn/openvpn-plugin-down-root.so 'umount -f /mnt/xxxxx'

At least on shutting down my notebook I don't have to wait those 180 seconds anymore.

[Rulatir (rulatir)]

Gotta love how people commenting here no longer even *HOPE* it will ever be fixed, and share workarounds instead.

[Sebastian Kügler (sebasje)]

Szczepan, I don't see how a snarky comment of yours is going to motivate anyone to put their time into this. I for one have removed myself from the CC: list of this bugreport, since the last thing I need is polemic remarks from bystanders. You're not making your life, or that of others easier.

[Rulatir (rulatir)]

> Szczepan, I don't see how a snarky comment of yours is going to motivate anyone to put their time into this.

I don't see why it necessarily couldn't work, and this appropach hasn't been tried yet, unlike much everything else that has been *proven* ineffective over the last five years.

[Tilman Vogel (tilman-vogel)]

For me, this is by far the most annoying problem I have with KDE because it happens to me every time I switch from wired network to wireless. So, I sympathize with Szczepan's frustration, even if that does not immediately help.

6th anniversary in February and a lot of votes makes me wish one of the people who could fix this quickly had a similar setup as I do. It would probably be fixed within days...

[Rdieter-math (rdieter-math)]

In a *constructive* vein, from looking that the most recent backtrace posted:

#0 0x00007ffff026aba5 in _lxstat () from /lib64/libc.so.6
#1 0x00007ffff01d2c65 in realpath@@GLIBC_2.3 () from /lib64/libc.so.6
#2 0x00007ffff24c9914 in KStandardDirs::realFilePath(QString const&) () from /usr/lib64/libkdecore.so.5
#3 0x00007ffff24955b3 in KMountPoint::List::findByPath(QString const&) const () from /usr/lib64/libkdecore.so.5
#4 0x00007ffff40638c1 in KDiskFreeSpaceInfo::freeSpaceInfo(QString const&) () from /usr/lib64/libkio.so.5
#5 0x00007fff3f8d2544 in SolidDeviceEngine::freeDiskSpace(this=this@entry=0x1a835c0, mountPoint=...) at /usr/src/debug/kde-workspace-4.11.1/plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp:653

looks like it gets stuck trying to get free/available space info.

That said, I *vaguely* recall seeing a reviewboard request covering this case recently. I'll go do some digging.

That said, can anyone confirm problem exists using latest kde-workspace-4.11.13 + kde-4.14.2 ? (latest confirmations I see still mention kde-4.13.x)

[aseigo (aseigo)]

This bug should perhaps be assigned to kdelibs, as it is not really a plasma bug ... thought it could be worked-around in kickoff. See Bug#316655 which has more information on the problem. The culprit is the free space checking code; it makes a blocking call and when the mount point is not available this simply hangs. This problem affects several KDE components (among other software out there) ... one possibility is to simply not show the free space in kickoff, though that probably involves moving away from PlacesModel (assuming that is what is still used). So a proper solution in the free space checker is probably the best approach.

My suggestion would be look at the filesystem type advertised for the mount point and simply avoid any free space (or similar info fetching) attempts on nfs, cifs, etc. and perhaps also fuse mounts.

@Szczepan "I don't see why it necessarily couldn't work, and this appropach hasn't been tried yet, unlike much everything else that has been *proven* ineffective over the last five years."

You are not the first person think that behaving badly will make things better. It has been tried many times in the past and honestly doesn't work.

Regardless of whether it works or not, it is not welcome in KDE. Please see: https://www.kde.org/code-of-conduct/

@Tilman Vogel: If you can not fix it yourself, and evidently people who may be able to are not motivated to do so, then perhaps paying someone to fix it would be a possibility. Not everything gets accomplished gratis. (No, I'm not interested in being paid to fix this :)

[Rdieter-math (rdieter-math)]

Thanks aaron (hugs), marking as dup

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

[Tilman Vogel (tilman-vogel)]

(In reply to Aaron J. Seigo from comment #99)
> @Tilman Vogel: If you can not fix it yourself, and evidently people who may
> be able to are not motivated to do so, then perhaps paying someone to fix it
> would be a possibility. Not everything gets accomplished gratis. (No, I'm
> not interested in being paid to fix this :)

That's an interesting suggestion - however, where do I find those people? It might actually be quite a good idea to invent an open-source job market where I could post "Who is going to fix https://bugs.kde.org/show_bug.cgi?id=184062 for € 20?" I am not sure about the legal implications, however... Actually, that could be integrated into the bug-tracking system. Instead of casting a vote, we could pledge a bounty. Every vote on this bug worth 10 ¢ would make this a 58 € bug already...

[Sebastian 'polrus' Tur (dpbasti)]

I fully support the bounty idea - it's brilliant, simple and it works for Elementary OS bug-figthing

[Rulatir (rulatir)]

@Aaron: "You are not the first person think that behaving badly will make things better. It has been tried many times in the past and honestly doesn't work."

That's not my experience, and probably not even yours. This is just your *wish* for a Politeness God to exist, rewarding the righteous and punishing the wicked. Meanwhile on planet Reality, I have been profusely thanked by people whose daily work was made easier because I got authors of certain software artifacts to fix critical bugs after everyone else had been polite with them for years.

"Regardless of whether it works or not, it is not welcome in KDE."

So there we have this conflict between two unwelcome things: behaving badly and long-standing critical bugs. Both are definitely unwelcome, but there is an interesting relationship between them:

 - the former can be used to hasten the elimination of the latter
 - if the latter remains, the former is inevitable anyway
 - when the latter is eliminated, the former also vanishes