Baloo 5.13 stops to index file after indexing (wrongly) some of them balooctl status Baloo File Indexer is running Indexer state: Indexing file content Indexed 2333 / 50691 files Current size of index is 53,11 MiB I tryed pretty everything, included 1) stop baloo and delete the database 2 ) remove akonadi 3) limitating indexing to one foder in baloofilerc 4) installing baloo 5.14 and kfilemetadata anda karchive 5.14 Few file indexed are indexed wrong. baloosearch and krunner show a lot of empty rows. Baloo doesnt consume RAM or CPU. It simply does nothing. Reproducible: Always
This is what happens after disablig and renabling baloo [guido@guido-pc ~]$ balooctl disable Disabling the File Indexer [guido@guido-pc ~]$ balooctl enable Enabling the File Indexer [guido@guido-pc ~]$ balooctl status Baloo Index could not be opened [guido@guido-pc ~]$ balooctl status Baloo Index could not be opened [guido@guido-pc ~]$
I experience the same behaviour. When index finally gets created (after few reboots maybe??) indexer stops (in my case) around ~600 files. However manual indexing (via balooctl index some-directory/*) does add those files to index and searching for specially tailored queries find the file (via baloosearch). It sometimes returns plenty of empty lines as well... baloo 5.14.0 (Arch)
I can confirm this behaviour with packages from Kubuntu Willy and with compiled sources from master. baloo_file stops doing any work short after start but blocks any call from balooctl status. In this situation invoking balooctl restart only claims that a process is already running and balooctl stop has no effect. Maybe this is some kind of dbus race?
@Luis. If baloo_file is blocking any call from balooctl status, could you please provide a backtrace? $gdb --pid `pidof baloo_file` > thread apply all backtrace
Here it goes. I recompiled from master, yesterday (2b81c5). Let me know if you need anything else. (gdb) thread apply all backtrace Thread 3 (Thread 0x7359bb40 (LWP 16348)): #0 0xb778dbe8 in __kernel_vsyscall () #1 0xb6d1e4fb in poll () at ../sysdeps/unix/syscall-template.S:84 #2 0xb577e980 in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb576ff1c in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb5770054 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb72757e3 in QEventDispatcherGlib::processEvents (this=0x72c00468, flags=...) at kernel/qeventdispatcher_glib.cpp:418 #6 0xb72182d3 in QEventLoop::processEvents (this=0x7359b198, flags=...) at kernel/qeventloop.cpp:128 #7 0xb7218722 in QEventLoop::exec (this=0x7359b198, flags=...) at kernel/qeventloop.cpp:204 #8 0x0806474e in Baloo::FileContentIndexer::run (this=0x8e651b8) at /home/lacsilva/Development/baloo/src/file/filecontentindexer.cpp:70 #9 0xb7042f31 in QThreadPoolThread::run (this=0x8f6ead0) at thread/qthreadpool.cpp:93 #10 0xb704665b in QThreadPrivate::start (arg=0x8f6ead0) at thread/qthread_unix.cpp:337 #11 0xb64772fc in start_thread (arg=0x7359bb40) at pthread_create.c:334 #12 0xb6d28bbe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122 Thread 2 (Thread 0x72bffb40 (LWP 16349)): #0 0xb778dbe8 in __kernel_vsyscall () #1 0xb6d20ce1 in select () at ../sysdeps/unix/syscall-template.S:84 #2 0xb71adfa9 in QProcessManager::run (this=0x8e52cd8) at io/qprocess_unix.cpp:264 #3 0xb704665b in QThreadPrivate::start (arg=0x8e52cd8) at thread/qthread_unix.cpp:337 #4 0xb64772fc in start_thread (arg=0x72bffb40) at pthread_create.c:334 #5 0xb6d28bbe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122 Thread 1 (Thread 0xb391f780 (LWP 16335)): #0 0xb778dbe8 in __kernel_vsyscall () #1 0xb647ca6c in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187 #2 0xb6d35cb6 in __pthread_cond_wait (cond=0x8ec8400, mutex=0x8ec83e8) at forward.c:149 #3 0xb7047833 in QWaitConditionPrivate::wait (time=4294967295, this=0x8ec83e8) at thread/qwaitcondition_unix.cpp:136 #4 QWaitCondition::wait (this=0x8ec83cc, mutex=0x8ec83b8, time=4294967295) at thread/qwaitcondition_unix.cpp:208 #5 0xb7041d01 in QThreadPoolPrivate::waitForDone (this=0x8ec8378, msecs=-1) at thread/qthreadpool.cpp:287 #6 0xb7041fa1 in QThreadPool::waitForDone (this=0xbfe3ef64, msecs=-1) at thread/qthreadpool.cpp:610 #7 0xb7041ff7 in QThreadPool::~QThreadPool (this=0xbfe3ef64, __in_chrg=<optimised out>) at thread/qthreadpool.cpp:416 #8 0x0805a346 in Baloo::FileIndexScheduler::~FileIndexScheduler (this=0xbfe3ef48, __in_chrg=<optimised out>) at /home/lacsilva/Development/baloo/src/file/fileindexscheduler.h:39 #9 Baloo::MainHub::~MainHub (this=0xbfe3ef1c, __in_chrg=<optimised out>) at /home/lacsilva/Development/baloo/src/file/mainhub.h:33 #10 main (argc=1, argv=0xbfe3f074) at /home/lacsilva/Development/baloo/src/file/main.cpp:87
@Luis: Thanks. This is a separate issue though. Filled a new bug 353559 @abulak: The empty lines should get fixed with the 5.15 release. You will need to reset your db though. $balooctl disable $balooctl enable.
I have the same problem on Manjaro Linux. Cannot complete indexing.
All of my issues have disappeared when I reinstalled my machine as 64 bit. For me all of this only happens (and it happens consistently) when on 32 bit machines.
Created attachment 94953 [details] attachment-19052-0.html I confirm. The bug is present only on 32 bit system Il 11/Ott/2015 17:38, "Luis Silva" <lacsilva@gmail.com> ha scritto: > https://bugs.kde.org/show_bug.cgi?id=352710 > > Luis Silva <lacsilva@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |CONFIRMED > Ever confirmed|0 |1 > > --- Comment #8 from Luis Silva <lacsilva@gmail.com> --- > All of my issues have disappeared when I reinstalled my machine as 64 bit. > For > me all of this only happens (and it happens consistently) when on 32 bit > machines. > > -- > You are receiving this mail because: > You reported the bug. >
I'm experiencing a similar problem in Kubuntu 15.10 - but I am in 64bit. So not sure the 32bit only assertion is correct.
I'm on 5.19 and indexing still stops (32bit system); @Vishesh: queries by baloosearch still return plenty of empty results (despite multiple database resets) And by the way: I found the ultimate switch: Add only basic indexing=true to the [General] section of ./.config/baloorc On my workstation (where indexing works as expected) Baloo indexes only filenames; this replaces fsrunner (almost) perfectly. (creating index took ~1s for 100k files, searches are instant!) How about adding a switch to gui for this extremely useful option? e.g. as a suboption under Enable File Search tickbox?
(In reply to abulak from comment #11) > How about adding a switch to gui for this extremely useful option? e.g. as a > suboption under Enable File Search tickbox? Feel free to add this suggestion as a comment to bug #351647.
Seeing the same problem here, though for me the problem is a crash of baloo_file_extractor: https://bugs.kde.org/show_bug.cgi?id=364748 I noticed this crash by: dmesg | grep baloo I would recommend you checking for crashes too.
Lack of progress is likely due to a crashed indexer process. Should be fixed with https://phabricator.kde.org/D16266 Content indexing can be disabled in System-Settings or using "balooctl config"