I set up NFS drives in the network and wanted to automount them with systemd via /etc/fstab. The entry is the following according to the Arch Linux Wiki: Computer:/Öffentlich /media/netzwerk/Computer/Öffentlich nfs noauto,soft,x-systemd.automount,x-systemd.device-timeout=10,timeo=14 0 0 After I set up the automount with systemd the taskbar freezes completely after some time or when I tried to mount an truecrypt/veracrypt volume. Reproducible: Always Steps to Reproduce: 1. Set up NFS 2. Make an entry in /etc/fstab to automount the nfs volume in the network with systemd (Details) 3. Start an plasma session 4. Wait some time or try to mount an truecrypt/veracrypt volume Actual Results: Taskbar freezes Expected Results: Taskbar doesn't freeze
After some testing, I could reduce the error on the systemd automount function itself. The error occures, when the network connection to the network folder is lost. The mount is not unmounted correctly, it throws errors and causes plasma 5 to freeze. I don't really know why this is happening as there is nothing I could find in the Internet except a very old thread. The systemd automount is completely broken and not usable for local networks at home, where computers are not availlable all the time. I do experiment with autofs now. It works better in these circumstances. I close this bug for now, because it is not a fault of plasma 5.
I reopened the bug as systemd automount is working with arch linux in command line. The bug sill remains with the newest versions auf plasmashell (5.4.3) and kde frameworks (5.16).
Hi all, I have the same problem. We are running opensuse and preparing to upgrade to OpenSuSe Leap 42.1. plasmashell from opensuse 42.1 package 5.4.2-4.1 Test desktop & laptop including standby/resume cycle with local home work fine - no issues. 2 Standard desktop configurations 1.) - autofs - problem appears to occur relatively quickly - minutes to a few hours 2.) - fixed mount - problem takes longer to show up - usually overnight / several hours Things tried / noticed - plasma shell starts consuming 1 CPU 100% - strace doesn't seem to show anything different than normal, but is clearly logging faster - appears to actually start when unlocking the screen (load monitoring indicates the CPU is idle overnight) - works if disconnecting screens, turning off screens, screen lock, dpms etc. - NFS/diskio is more-or-less idle - autofs seems to make it worse especially if unused auto-mounted drives become unmounted - eliminated all widgets on the toolbar - this has no effect - tested XFCE, TWM, LXDE, Gnome, and old KDE4 desktop - all without problem. - restart plasmashell from a terminal - lot's of messages but nothing that seems different between when it is behaving and not behaving. Ctrl-c and start again makes it useable again.
Can you find out where we're frozen please? when we're frozen do: sudo gdb --pid `pidof plasmashell` then type "bt" and paste that.
Here you go (gdb) bt #0 0x00007fb79ee5dbe7 in ioctl () at /lib64/libc.so.6 #1 0x00007fb79f6c5d9d in () at /usr/lib64/libQt5Core.so.5 #2 0x00007fb79f665b9c in () at /usr/lib64/libQt5Core.so.5 #3 0x00007fb79f667335 in () at /usr/lib64/libQt5Core.so.5 #4 0x00007fb79f75d996 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #5 0x00007fb79f7de9fe in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /usr/lib64/libQt5Core.so.5 #6 0x00007fb79f76a759 in QSocketNotifier::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #7 0x00007fb7a0aa6e8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #8 0x00007fb7a0aabcd8 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #9 0x00007fb79f72dba5 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #10 0x00007fb79f785975 in () at /usr/lib64/libQt5Core.so.5 #11 0x00007fb79b54dc84 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #12 0x00007fb79b54ded8 in () at /usr/lib64/libglib-2.0.so.0 #13 0x00007fb79b54df7c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #14 0x00007fb79f784a3c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #15 0x00007fb79f72ba63 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #16 0x00007fb79f7335d6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #17 0x000000000043467b in main ()
Maybe also of note is that "Alt-Tab" works fine ... it is only the taskbar that hangs (it is reponsive but each click takes ca 5 seconds to react). (Also at the bottom is the console output of plasmashell). Here the strace output too - (currently my widgets are - network monitor, system load (with swap monitor disabled), Device Notifier(removable only), Clock). The following is being repeated several thousand times per second. read(23, "itions/localssd/usedspace\tintege"..., 65536) = 65536 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=19, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=26, events=POLLIN}, {fd=28, events=POLLPRI}, {fd=29, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}], 13, 1318) = 1 ([{fd=23, revents=POLLIN}]) ioctl(23, FIONREAD, [65536]) = 0 read(23, "reespace\tinteger\npartitions/loca"..., 65536) = 65536 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=19, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=26, events=POLLIN}, {fd=28, events=POLLPRI}, {fd=29, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}], 13, 1317) = 1 ([{fd=23, revents=POLLIN}]) ioctl(23, FIONREAD, [65536]) = 0 file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:37: TypeError: Cannot read property 'flat' of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:38: TypeError: Cannot read property 'hovered' of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:124: TypeError: Cannot read property 'text' of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Base/ButtonStyle.qml:83: TypeError: Cannot read property 'menu' of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:96: TypeError: Cannot read property of null
My output is: #0 0x00007fc5dc3b5c97 in statfs64 () from /usr/lib/libc.so.6 #1 0x00007fc5dc3b5d06 in statvfs64 () from /usr/lib/libc.so.6 #2 0x00007fc5d58df6dd in KDiskFreeSpaceInfo::freeSpaceInfo(QString const&) () from /usr/lib/libKF5KIOCore.so.5 #3 0x00007fc516aa9bf6 in ?? () from /usr/lib/qt/plugins/plasma/dataengine/plasma_engine_soliddevice.so #4 0x00007fc516aaac6f in ?? () from /usr/lib/qt/plugins/plasma/dataengine/plasma_engine_soliddevice.so #5 0x00007fc516abb1a4 in ?? () from /usr/lib/qt/plugins/plasma/dataengine/plasma_engine_soliddevice.so #6 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #7 0x00007fc516abaeec in ?? () from /usr/lib/qt/plugins/plasma/dataengine/plasma_engine_soliddevice.so #8 0x00007fc516ab6ba0 in ?? () from /usr/lib/qt/plugins/plasma/dataengine/plasma_engine_soliddevice.so #9 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #10 0x00007fc5e235c4f4 in Solid::StorageAccess::accessibilityChanged(bool, QString const&) () from /usr/lib/libKF5Solid.so.5 #11 0x00007fc5e235faa0 in ?? () from /usr/lib/libKF5Solid.so.5 #12 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #13 0x00007fc5e235acc4 in ?? () from /usr/lib/libKF5Solid.so.5 #14 0x00007fc5e235605e in ?? () from /usr/lib/libKF5Solid.so.5 #15 0x00007fc5e235f7e9 in ?? () from /usr/lib/libKF5Solid.so.5 #16 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #17 0x00007fc5e235ac12 in ?? () from /usr/lib/libKF5Solid.so.5 #18 0x00007fc5e235cd59 in ?? () from /usr/lib/libKF5Solid.so.5 #19 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #20 0x00007fc5e235ac62 in ?? () from /usr/lib/libKF5Solid.so.5 #21 0x00007fc5e2352458 in ?? () from /usr/lib/libKF5Solid.so.5 #22 0x00007fc5e235ce3d in ?? () from /usr/lib/libKF5Solid.so.5 #23 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #24 0x00007fc5dccd512a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #25 0x00007fc5dcd5501e in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () from /usr/lib/libQt5Core.so.5 #26 0x00007fc5dcce1c4b in QSocketNotifier::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #27 0x00007fc5de08601c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #28 0x00007fc5de08b4f6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #29 0x00007fc5dcca69ab in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #30 0x00007fc5dccfd81d in ?? () from /usr/lib/libQt5Core.so.5 #31 0x00007fc5d8803dc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #32 0x00007fc5d8804020 in ?? () from /usr/lib/libglib-2.0.so.0 #33 0x00007fc5d88040cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #34 0x00007fc5dccfd34f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #35 0x00007fc5dcca437a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #36 0x00007fc5dccac33c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #37 0x00000000004300f3 in main ()
Same issue here. Distro : Arch Linux Kernel : 4.5.1 Plasma-workspace 5.6.3 plasma-framework 5.21.0 Taskbar is back to normal if I 'umount -f' the network drive.
I don't understand why this bug has status WAITINGFORINFO. What information do you need? I can confirm this bug is present in multiple distributions. I've verified it happens on openSuse Leap, Debian Testing and Arch. Root cause is quite precisely pinpointed in Arch wiki: https://wiki.archlinux.org/index.php/KDE#Freezes_when_using_Automount_on_a_NFS_volume
If it hangs in ioctl(), then the network share is not accessed via KIO, but accessed via a mount point. It is expected that the call hangs when the network share does not respond, and is the primary reason why we still have KIO.