KDE apps short freezes after file/directory content changes

English Applications
#1

Hello all,

Since Opensuse switched to the Plasma 5 desktop (when selecting KDE), I experience very annoying short freezes.
This is going on for a couple of years now during different versions of Opensuse. Now I’m using Leap 42.2 and the problem
is still there. I haven’t tried Leap 42.3 yet because I always wait 3/4 months till most severe bugs have been patched.

The reason I post it now is because I found a way to reproduce the problem.

  1. Open a directory with Dolphin that contains just a couple of files.

  2. Open Okular and open a pdf (a random pdf that resides in another directory is fine).

  3. In Okular, select File → Save Copy As… and save a copy of the opened pdf in the directory that is opened in Dolphin.

  4. Immediately after doing that, switch to the Dolphin window. Dolphin will be frozen for 3 to 5 seconds before showing the
    new file in the directory. If the Dolphin window was covered by the Okular window, the Dolphin window will be gray during the freeze.

The strange thing is, this happens just on one pc only. Another pc with the same software does not show this phenomena.

Also, only KDE apps show these freezes. All other applications not using the KDE framework never suffer from these freezes.

I already switched off search etc. All partitions on all harddisks are formatted with ext4.

I have separate partions for / and for data and /home like on another pc that doesn’t suffer from these freezes.

Any ideas?

#2

I just remembered that after installing Leap 42.2 from scratch, these freezes were not noticable.
They started to appear after some time and slowly became more severe.
So, I did a quick test by creating a new user and I can not reproduce the freeze when using the new account…:?

But still, I don’t know how to solve this annoying problem. Deleting all settings and preferences isn’t an option.

#3

One way would be to go into the new account, then copy your settings and preferences over one or two config files at a time. When the problem shows up there, you will most likely know which config file is involved.

Then, you can flip back to your original account, copy that config file to a backup file just in case, and rebuild that one config file.

You could later compare the two config files before and after to see if you can spot the offending item, so you actually will know what caused the problem.

If you do that, you could report back here so others could learn from what you find out.

#4

I logged out and renamed the following directories:

/home/$user/.cache
/home/$user/.config
/home/$user/.local
/home/$user/.kde4

I emptied the cache:

$> cd /var/tmp/kdecache-$user/
$> find . -type f -exec rm ‘{}’ ‘;’
$> cd ~$user/.cache
$> find . -type f -exec rm ‘{}’ ‘;’
$> cd ~$user/.thumbnails
$> find . -type f -exec rm ‘{}’ ‘;’

I performed the following actions:

cd /etc/tmpfiles.d

cp -v /usr/lib/tmpfiles.d/tmp.conf .

nano tmp.conf

This file is part of systemd.

systemd is free software; you can redistribute it and/or modify it

under the terms of the GNU Lesser General Public License as published by

the Free Software Foundation; either version 2.1 of the License, or

(at your option) any later version.

See tmpfiles.d(5) for details

Clear tmp directories separately, to make them easier to override

SUSE policy: we don’t clean those directories

q /tmp 1777 root root 7d
q /var/tmp 1777 root root 14d

Exclude namespace mountpoints created with PrivateTmp=yes

x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-/tmp
x /var/tmp/systemd-private-%b-
X /var/tmp/systemd-private-%b-*/tmp

man tmpfiles.d

So far, no cigar…

In addition, I discovered the following problem:

After starting Yast2 (Yast control center) and selecting System -> Partitioner,
it shows an empty list with a waiting cursor when gathering info (as usual),
but it takes a full minute and during that minute, it takes one cpu core (100% cpu usage in top).
Normally this process should take no longer than 10 seconds.

#5

One thing to note with respect to Leap 42.2 is, ‘baloo’ – the file indexer. It’s been changed with Leap 42.3 to not index quite so much – with Leap 42.2 it pays to keep an eye on what’s going on.

One information source is the KDE Info Center – the File Indexing tab.

Another is, the KDE System Settings – Search module.Normally, only the entire $HOME folder is indexed.

A Terminal CLI command may also provide some helpful information:


 > balooctl status
Baloo File Indexer is running
Indexer state: Indexing file content
Indexed 25970 / 25970 files
Current size of index is 346.41 MiB
 >
#6

Thanks for the help but Baloo isn’t running. It’s one of the things I immediately switch-off permanently after installing Opensuse & KDE.
I know how to organize my harddrives and directories in order to find my documents. No need for search-nonsense here.

#7

Then, possibly, a file system issue:

If Btrfs and a “not-always-on” system such as a Laptop then, with a CLI and the user “root” select the /etc/cron.monthly/ and /etc/cron.weekly/ Btrfs cron jobs and run them manually and, remember to do this occasionally.

File systems such as XFS and ext4 are usually not the cause of such behaviour.

#8

Thanks for the help but btrfs is not in use here and never will (no offense).

There are four harddrives in the pc:

  1. SSD Samsung pro ext4 which contains the system partition mounted as / (including /home)

  2. NTFS contains a windows 7 installation. Not mounted

  3. 2TB WD ext4 blue with the partition that contains the “Documents” directory.

  4. 4TB WD black ext4 with multimedia files

Disk are 1, 2 and 4 have been installed about 6 months ago. Before there were Seagate harddrives. Same problem by the way…

It’s definitely not a hardware problem because only Qt applications that are part of the KDE framework like Dolphin, Okular, Kate, Okteta, KTorrent, Yast2, etc. suffer from
this problem. Or it must be a hardware problem that affects only KDE plasma 5???
My own programs written in C/C++ which uses the Qt framework for the gui also don’t suffer from this problem.

#9

Or, maybe, a disadvantage of “Declarative Qt programming”, QML and the Qt WebEngine. On the other hand, Qt Wayland, which seems to be quite successful in the Embedded systems area, may have been one of the major reasons for the decision to move to “Declarative Qt programming”.

You don’t mention if your own Qt applications are written using “Imperative Qt programming” or “Declarative Qt programming”.

#10

The problem seems to disappear when I remove the network cable from the pc…!?!&$??

#11

I used Wireshark to see what’s going on.
When the freezes happens, the network connection is flooded with DNS requests:


No.     Time           Source                Destination           Protocol Length Info
      1 0.000000000    192.168.1.2           192.168.1.1           DNS      73     Standard query 0x53ae A cetriolo.suse

Frame 1: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) on interface 0
Ethernet II, Src: AsustekC_c9:f2:f1 (48:5b:39:c9:f2:f1), Dst: Netgear_7f:3a:10 (28:c6:8e:7f:3a:10)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 192.168.1.1
User Datagram Protocol, Src Port: 38071, Dst Port: 53
Domain Name System (query)

No.     Time           Source                Destination           Protocol Length Info
      2 0.000017735    192.168.1.2           192.168.1.1           DNS      73     Standard query 0xd632 AAAA cetriolo.suse

Frame 2: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) on interface 0
Ethernet II, Src: AsustekC_c9:f2:f1 (48:5b:39:c9:f2:f1), Dst: Netgear_7f:3a:10 (28:c6:8e:7f:3a:10)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 192.168.1.1
User Datagram Protocol, Src Port: 38071, Dst Port: 53
Domain Name System (query)

No.     Time           Source                Destination           Protocol Length Info
      3 0.011026167    192.168.1.1           192.168.1.2           DNS      148    Standard query response 0x53ae No such name A cetriolo.suse SOA a.root-servers.net

Frame 3: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) on interface 0
Ethernet II, Src: Netgear_7f:3a:10 (28:c6:8e:7f:3a:10), Dst: AsustekC_c9:f2:f1 (48:5b:39:c9:f2:f1)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.2
User Datagram Protocol, Src Port: 53, Dst Port: 38071
Domain Name System (response)

No.     Time           Source                Destination           Protocol Length Info
      4 0.011628077    192.168.1.1           192.168.1.2           DNS      148    Standard query response 0xd632 No such name AAAA cetriolo.suse SOA a.root-servers.net

Frame 4: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) on interface 0
Ethernet II, Src: Netgear_7f:3a:10 (28:c6:8e:7f:3a:10), Dst: AsustekC_c9:f2:f1 (48:5b:39:c9:f2:f1)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.2
User Datagram Protocol, Src Port: 53, Dst Port: 38071
Domain Name System (response)

No.     Time           Source                Destination           Protocol Length Info
      5 0.011700108    192.168.1.2           192.168.1.1           DNS      68     Standard query 0x8681 A cetriolo

Frame 5: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface 0
Ethernet II, Src: AsustekC_c9:f2:f1 (48:5b:39:c9:f2:f1), Dst: Netgear_7f:3a:10 (28:c6:8e:7f:3a:10)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 192.168.1.1
User Datagram Protocol, Src Port: 33958, Dst Port: 53
Domain Name System (query)

Btw, “cetriolo” is the name of the pc…

When I start Yast2 and go to System -> Network Setting -> Hostname/DNS and check the option “Assign Hostname to Loopback IP”,
the freezes seem to disappear.

Any ideas?

#12

The normal assumption is that, assigning the Hostname to the loopback IP address (127.0.0.2) “is a useful option if you want to have the host name resolvable at all times, even without active network”. See: <https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.basicnet.html#sec.basicnet.yast>

But, the help in YaST gives a little more information: “Be careful with this setting if your machine is offering Network Services”.

But, it seems that, the current KDE and/or Qt world has some issues if the Hostname is not assigned to the loopback IP address.

Therefore, it seems that, it’s advisable that, currently, machines with a KDE GUI should – in all cases – assign the Hostname to the loopback IP address.

#13

Can you point me to some sources regarding the issues with KDE/Qt in case hostname is not assigned to loopback IP address?

This raises all kind of questions.

Why I can not reproduce the problem at work where my pc is running the same distro and version and desktop?

Why the problem doesn’t seem to appear when I create a new user and use that to login?

Some info that could or could not be related to this problem: I’m running a Samba server that shares some directories which contains multimedia files.
That way my mediaplayer can directly access them via the network.
I did that by using Dolphin and rightclicking on some directories and selecting the “Share” tab.

Later, when I have time, I’ll disable the Samba server and see what happens.

#14

Way back in 2005, someone in Romania mentioned that:

Is loopback interface correctly set up?
A non-working loopback interface can mess up KDE.

There’s also this openSUSE Forums thread from 2012 which is dealing with Firefox taking a considerable amount of time to start under KDE: <https://forums.opensuse.org/showthread.php/478160-Firefox-starts-slowly>

  • ‘nrickert’ mentioned “You need “localhost” there. You can put both names on the one line.”

You could contact ‘nrickert’ to ask if he has some real background as to why.
Failing that, I can only suggest a support question to the Qt folks.

#15

I did some more tests and I’m now able to reproduce the problem on another Opensuse box with Leap 42.2 & KDE.

In Yast2, enable/setup a Samba server. Startup -> During Boot. Shares -> Disable all available shares. Check Allow Users to Share Directories. Check Allow Guest Access.

In Dolphin, select a couple of directories to share. Rightclick on it and select Properties -> Share. Check Share with Samba. Check Allow Guests.

Reboot.

Start Wireshark and filter on DNS packets only.

Start a couple of KDE-libs dependant applications like Kate (preferably with th filesystem browser plugin activated), Okular, Dolphin, and perform some file manipulations (copy/edit/whatever).

Look what happens in Wireshark.

A temporary workaround is to open Yast2 -> System -> Network Settings -> Hostname/DNS and check Assign Hostname to Loopback IP.
It will make the desktop usable again but still not snappy.
For a snappy KDE experience, you can’t share directories using the above setup.

I’m going to try to report this bug but don’t have high hope they wanna fix it.
I have reported some KDE bugs in the past and they (Opensuse and/or KDE) never rolled out an official update for the present distribution the bug was reported for.
But at least nobody can blame me for not reporting it.