https://bugs.kde.org/show_bug.cgi?id=433204
--- Comment #30 from Peter Wibberley <p.wibber...@btinternet.com> --- Following tagwerk19's suggestion (Comment21), I've rerun 'strace baloo_file', making sure not to index the file I'm logging the strace output to. This has saved about 130,000 lines of output. Thank you, tagwerk19! The final 20 lines of strace output, from Line 85841 onwards, are now, openat(AT_FDCWD, "/home/peter/Music/Marc Maron", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 15 fstat(15, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 getdents64(15, /* 10 entries */, 32768) = 520 getdents64(15, /* 0 entries */, 32768) = 0 close(15) = 0 openat(AT_FDCWD, "/home/peter/Music/Dirk Gently Series x", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 15 fstat(15, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 getdents64(15, /* 8 entries */, 32768) = 528 getdents64(15, /* 0 entries */, 32768) = 0 close(15) = 0 poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLPRI}, {fd=11, events=POLLIN}, {fd=14, events=POLLIN}], 5, 2577) = 0 (Timeout) write(3, "\1\0\0\0\0\0\0\0", 8) = 8 poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLPRI}, {fd=11, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 1 ([{fd=3, revents=POLLIN}]) read(3, "\1\0\0\0\0\0\0\0", 16) = 8 futex(0x55d72a31eca0, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x55d72a31ec50, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x55d72a043578, FUTEX_WAKE_PRIVATE, 1) = 1 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLPRI}, {fd=11, events=POLLIN}, {fd=14, events=POLLIN}], 5, 115985 <unfinished ...>) = ? +++ killed by SIGSEGV +++ So, I'm still getting "+++ killed by SIGSERV +++", which presumably explains why baloo stops running. A bit odd, is the 3 "poll" messages. Earlier in the log file, these occur only about once every 7000 lines, until this trio of them in the final few lines. There's about 12000 instances of inotify_add_watch. Running 'find . -type d -print| wc -l' tells me I have nearly 36,000 directories. I don't know how many of these are excluded from file indexing, so I can't say whether I've got an 'inotify_add_watch' for every indexed directory, but I guess it's possible. Earlier this evening, I was getting only 8000 instances of inotify_add_watch, until I realised that max_user_watches had reverted to 8192, and I increased it up to 129762 again. Before increasing the limit, there was also "ENOSPC (No space left on device)" appended to the last 450 or so 'inotify_add_watch' messages. At the moment, I can't think of anything that could have suddenly increased the number of directories way over 8000 or so on or about 17th December, when the problem started, but may be there was. But when I increase the limit to circa 130,000, the problem doesn't go away: could there also be some parameter, other than max_user_watches, which is still too low, and causing the SIGSEGV fault? Any clues here as to what's going wrong? Thanks and regards -- You are receiving this mail because: You are watching all bug changes.