Hi all,

I recently installed KF5 + Plasma 5.1 and try to index some files. However, it seems that baloo fails to index some files and kind of "hang" at this file with continuous cpu usage (process baloo_file_extractor).

> balooctl status
Baloo File Indexer is running
Indexed 879 / 890 files

Does anybody has an idea how to circumvent this issue? Should I post this as a bug?

I'm seeing a similar problem with KDE 4.14.2 running on FreeBSD 10.1-RELEASE except that the indexing exits instead of hanging.
It seriously underestimates the total number of files and never gets beyond indexing 1078 files

Code: Select all

curlew:/home/mike% balooctl status
Baloo File Indexer is running
Indexed 1078 / 20577 files
Failed to index 0 files

I have noticed that KDE on FreeBSD still has some dependencies on nepomuk

Code: Select all

curlew:/home/mike% pkg info -x --required-by nepomuk which I understand has been replaced by baloo.
nepomuk-core-4.14.2_1:
        kactivities-4.13.3
        kactivitymanagerd-4.13.3
        kde-workspace-4.11.13_1
        nepomuk-widgets-4.14.2
        kget-4.14.2
        kdepim-runtime-4.14.2
        kde-runtime-4.14.2_2
        kde-baseapps-4.14.2
nepomuk-widgets-4.14.2:
        kget-4.14.2
        kde-baseapps-4.14.2
        kdepim-4.14.2_1

Could this be the cause of my problem?

@howgill, I think the baloo problem is with the USF file system. Seems the USF do not support xattr, therefore the baloo problem.
Please, read more about this issue here: http://vhanda.in/blog/2014/08/extended-attributes-updates/.

Seems that FreeBSD will no longer work with semantic desktop .

Have a nice new year!.

Please notice that FreeBSD supports xattr on UFS1, UFS2 and ZFS.

----
Both entries should be basically the same issue, indexing is stalled at file 1078 resp. file 879.

a) Check whether the indexer is actually still running:

Code: Select all

ps ax  | grep baloo_file_extractor

b) check which files are opened (while it hangs)

Code: Select all

for ((i=0;i<20;++i)) ; do date -u >> /tmp/baloo.dbg; lsof | grep baloo_fi >> /tmp/baloo.dbg; done

Paste /tmp/baloo.dbg somewhere so that baloo devs can examine it (I assume it's ok to file a bug in this case)
If the indexer actually crashed, things may get more complicated.

As a general reminder: a continuous read error *may* indicate a failing HDD. You may want to check smartctl on it to read out its health status.

luebking wrote:Please notice that FreeBSD supports xattr on UFS1, UFS2 and ZFS.

I don't know about UFS but zfs on FreeBSD 10.1 does not appear to support xattr:

Code: Select all

[root@curlew ~]# zfs get xattr sys/DATA/home
NAME           PROPERTY  VALUE  SOURCE               
sys/DATA/home  xattr     off    temporary
[root@curlew ~]# zfs set xattr=on sys/DATA/home
property 'xattr' not supported on FreeBSD: permission denied 

a) Check whether the indexer is actually still running:

Code: Select all

ps ax  | grep baloo_file_extractor

Yes it is

Code: Select all

[root@curlew ~]# ps ax  | grep baloo_file_extractor
4419  3  S+     0:00.00 grep baloo_file_extractor

b) check which files are opened (while it hangs)

Code: Select all

for ((i=0;i<20;++i)) ; do date -u >> /tmp/baloo.dbg; lsof | grep baloo_fi >> /tmp/baloo.dbg; done

Paste /tmp/baloo.dbg somewhere so that baloo devs can examine it (I assume it's ok to file a bug in this case)

OK, done that, it's at https://www.dropbox.com/s/jq18ezka9ao9933/baloo.dbg?dl=0. There's over 160 files listed in each iteration and they don't appear to change between iterations. I suppose the lack of support for xattr could be the cause except that I'd expect baloo to just not attempt to do any indexing if that was the case instead of getting stuck with lots of files open.
So I suppose I ought to file a bug report.

As a general reminder: a continuous read error *may* indicate a failing HDD. You may want to check smartctl on it to read out its health status.

My zpool has 2 disks mirrored so I'd not expect read errors. Smartctl shows both drives to be OK.

/var/db -- 3a114eb8ff7128eaeed6b7525120b7d1-le64.cache-4

No idea what that is, but they look fishy - at least and afaik, baloo should not be indexing around there.