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?