System freezes when renaming/moving to trash some particular folders
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
System freezes when renaming/moving to trash some particular folders
I've got a new system and something strange is happening using the latest -current.
Basically when I delete, rename or move to trash some folders the whole system freezes for 5secs approx.
It doesn't happen with every folder, only some particular locations, for example stuff in .local/share/icons, and sometimes when using slackpkg (I guess when it deletes files from old packages), and it's reproducible.
Anyone has an idea how can i further debug this? Already did a disk test and it seems healty.
On such an occasion, it might also be interesting to study the status from top. Is the machine load increasing? Are processes waiting for disk? Are processes consuming CPU? Does the swap usage increase? Does the amount of memory used for buff/cache hange?
If your system has a LED flashing at disk activity it might also be interesting to study the behavior of that LED. Does it constantly light up at such occasions?
Are you moving data between different partitions? If so, how much data? During the years, I have at some occasions seen problems with file servers with much RAM (about 256 GB) and spinning disks when moving, copying or writing big amounts of data to a partition. What happens then is that everything initially is very fast when the new data is cached/buffered in RAM. However, when the file server runs out of RAM it decides to flush all cached/buffered data at once and the entire system goes down to a crawl. However I don't think your problem comes from this as you "only" have 32 GB and a quick SSD drive.
Running the commands with strace, it returns instantly and then the freeze happens. In a separate htop window sometimes I was able to see a dolphin process or a kio process at 80+ percent of CPU but htop itself was not updating for some seconds until the freeze end.
Below the output of one of the strace that was followed by a brief freeze.
Curiously I tried repeating the steps in a windowmaker session and there everything is smooth, perhaps there's something plasma is doing under the hood, like putting watchers on some folders (these experiments were made in the local user icons folder) and locking the desktop when one of these goes away abruptively with a move or delete action.
I forgot to mention that I'm running with the proprietary nvidia driver, the plasma session is X11 and the bootloader is grub.
EDIT: for henca, I'm using a single ext4 root partition in the ssd, there's should be no issue there. I'm also using swap in zram with the swapinzram slackbuilds of marav, but I don't think thats the issue, since this was happening also in the beginning of my installation, where I used a regular swap partition of 2GB from the SSD, also my 32GB of ram were practically empty during the tests, plenty of room to allocate whatever the system wants
mv should be quick within a single partition and your strace output also shows that it all completed within the same second 16:00:14. The simple rename function call only took 0.000031 seconds (that is 31 us).
Like you, I guess that it is something in Plasma that gets confused about files moving around. The fact that such a process can freeze your entire system could be explained by real time priority processes occupying all CPU on threads on a machine, but modern CPUs usually have plenty of cores. It might rather be Plasma itself that stops updating graphics when some other part of Plasma is doing work.
As you have already found that the problem does not occur in another desktop environment things has been narrowd down to Plasma.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.