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.
