https://bugs.kde.org/show_bug.cgi?id=433204
--- Comment #34 from Peter Wibberley <p.wibber...@btinternet.com> --- (In reply to tagwerk19 from comment #31) > (In reply to Peter Wibberley from comment #30) > > ... Any clues ... > First off, I'd say create a file > /etc/sysctl.d/40-neon-inotify.conf > as per comment #12 (at least until 5.11). That would set the > max_user_watches every reboot. > > Then I'd see if > coredumpctl > gave a list of dumps as per comment #23 > > If it does, and you can get a backtrace, that would be a step forward. Tagwerk19, Sorry about the long gap, but life got in the way for a couple of months. In the meantime, I migrated from Neon LTS to the User Edition (using the instructions at https://userbase.kde.org/Neon/LTS/EOL). I had hoped that this might cure the problem, but alas not. The situation now is as follows: (1) If I use the default value for fs.inotify.max_user_watches of 8192 and run 'balooctl enable', I get a stream of messages, "kf.baloo: KDE Baloo File Indexer has reached the inotify folder watch limit. File changes will be ignored." (2) If I just double fs.inotify.max_user_watches to only 16384, and run 'balooctl enable', the watch limit error messages stop. However, 'balooctl status' shows the Baloo File Indexer as stopping after a few seconds. (3) If I run 'balooctl enable', wait for it to stop, and then run 'coredumpctl gdb <PID>', as you recommended, I get, #0 0x00007f1aff1919f4 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #1 0x00007f1aff194e80 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #2 0x00007f1aff195165 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #3 0x00007f1aff195892 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #4 0x00007f1aff195ed4 in mdb_get () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #5 0x00007f1b0069d458 in Baloo::IdFilenameDB::get(unsigned long long) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #6 0x00007f1b006921aa in Baloo::DocumentUrlDB::get(unsigned long long) const () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #7 0x00007f1b006afa19 in Baloo::Transaction::documentUrl(unsigned long long) const () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #8 0x000055fa2c6779f3 in ?? () #9 0x00007f1b006be7ac in Baloo::WriteTransaction::removeRecursively(unsigned long long, std::function<bool (unsigned long long)> const&) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 ... #65486 0x00007f1b006be7fe in Baloo::WriteTransaction::removeRecursively(unsigned long long, std::function<bool (unsigned long long)> const&) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #65487 0x000055fa2c67811c in ?? () #65488 0x00007f1b001f5ff2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #65489 0x00007f1b001f2bec in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #65490 0x00007f1aff200609 in start_thread (arg=<optimised out>) at pthread_create.c:477 #65491 0x00007f1affd25293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (4) I've also run strace when the indexer is still running and again when it's stopped, and the outputs look completely different. If it's running, the strace terminates in an orderly manner, but if the indexer isn't running then I get the SEGV fault. The fault seems to occur when a poll command gets a timeout. No idea what to make of all this! I would try a fresh install, but I had hoped the switch to the User Edition would achieve the same thing. Any suggestions? As ever, many thanks and regards Peter -- You are receiving this mail because: You are watching all bug changes.
