After upgrading from x11/kde4 to x11/kde5, I found there is a process called 'baloo_file' which seems to use a lot of system resources. If I forget to kill it within minutes after starting a GNOME session, the entire system will freeze. Yes, installing KDE can affect GNOME, as /usr/local/etc/xdg/autostart/baloo_file.desktop has X-GNOME-Autostart-enabled=true. I can change it to false to avoid the problem in GNOME, but it sounds like a workaround.
When baloo_file freezes the system, I can still move the mouse but no desktop applications are responding. SSH server becomes almost non-responsive and it takes several minutes just to get a login shell. Typing any simple commands such as 'killall' takes minutes to complete, and even logging in from a local VT is hard. When you type your user name, it takes several minutes to show the password prompt. If you press Ctrl-T at that time, you will see the following message.
load: 0.47 cmd: login 1141 [vlruwk] 204838.88r 0.00u 0.00s 0% 240
Most of the time it is stuck at [vlruwk] or [ufs] while the system load is low. I am not sure whether it is related to the number of files under my home directory. My home directory has about 2500000 files because I store hundreds of git repositories, mostly GNOME source code, and builds of GNOME and FreeBSD in it.
You can disable baloo via "balooctl disable". Or you can configure it to not index certain directories.
It would be interesting to know how many files baloo_files has open, and how many are free / available by the system.
I suspect this might be related to the fact that SDDM doesn't apply resource limits. There's a patch for this: https://reviews.freebsd.org/D17297
Could this be related to bug #234830?
(In reply to Martin Birgmeier from comment #3)
I don't think so. The file in this one just seems to hang libtiff.
I've just realized that even with SDDM patched to apply resource limits, there is no default limit for "openfiles".
Would it be possible to modify libinotify to limit itself to eg half of kern.maxvnodes?
(In reply to Edward Tomasz Napierala from comment #5)
Probably yes -- over to the maintainer of libinotify.
From bug 257227 comment 1 (emphasis more on baloo_file_extractor than on baloo_file):
> … I should, ideally, positively identify the cause of
> hogging in my case, but this will be a bug for another day.
(In reply to Tobias C. Berner from comment #1)
> … It would be interesting to know how many files baloo_files
> has open, and how many are free / available by the system.
Reading the above _loosely_ alongside bug 234830 (closed, fixed) …
If it's true that some types of file are more likely to trigger high CPU usage, when handled by baloo_file or baloo_file_extractor, will it help to identify those types?
> Baloo relies on KFileMetaData to extract content from the files.
> KFileMetadata ships with a number of plugins which can be enabled
> or disabled. We recommend shipping all KFileMetaData plugins. Specially
> ffmpeg by default. Without the indexers, Baloo cannot function to its
> full potential.
% pkg info --list devel/kf5-kfilemetadata | grep plugins
% uname -KrU
14.0-CURRENT 1400025 1400025
% pkg info -x metadata
(In reply to Tobias C. Berner from comment #1)
balooctl disable -- does not seems to work on FreeBSD 13-p4 amd64. At least I issued that command, output claims baloo is disabled, but then when startx launches kde5 baloo is again back in business on freezing my machine.
(In reply to Graham Perrin from comment #7)
I've just started to get baloo releted freezez recently. This is on freebsd 13-p4 on amd64. I keep system patched and does not remember any change other than
(1) populating home directory with several qemu soutre trees
(2) putting 2 qemu raw disk images into the home directory.
I guess (2) here is probably the culprit. Both images do have 22GB each. Both are in raw format with .raw extension.
(In reply to Karel Gardas from comment #10)
Looks like I've been mistaken. I've removed baloo core and whole src directory content from home and viola kde5 started to behave well. I've even make sure balooctl is enabled and restarted and again no problem.
So what seems to do problem in my case was either:
- 256GB of baloo core file
- src content which was configured and *compiled* trees of:
(i) llvm-12.0.1 whole project tree
(ii) qemu 5.1.0 tree
(iii) qemu 5.2.0 tree
(iv) qemu 6.1.0 tree
The file system in my case is ufs with default config (journaled and soft-updates).
(In reply to Karel Gardas from comment #11)
Found some time, made 7 subdirs in src and unpacked into each llvm-project-12.0.1.src.tar.xz and baloo is freezing my box again.
Although box is freezing and kde is unresponsive, before whole unpacking I've started few shells with `iostat 1` and top and I can see that box is >90% idle and there is nearly no I/O traffic. So where freezing is happening? Any advice how to debug that? Any d-trace hints? Thanks!
Also in my setup with 7 llvm 12 project trees. It looks like baloo is not the main cuprit in freeze as it finishes its business, or claims to so:
$ balooctl status
Baloo File Indexer is not running
Total files indexed: 228,151
Files waiting for content indexing: 0
Files failed to index: 3
Current size of index is 1.24 GiB
and yet, machine is basically neraly unusable on command-line (ssh) and completely unusable in KDE.
The system is not freezing, it runs into the vnode limit and there obtaining new vnodes is rate limited to 1 per second, which is arguably rather buggy and should be fixed.
In the meantime you can bump sysctl kern.maxvnodes