strigidaemon causes 100% CPU and crashes after a while

[Florian Reinhard]

Hi!

on my just installed kubuntu-tribe3 i noticed that the cpu-fan was running all the time. Top showed me that strigidaemon was running at nearly 100% all the time. strigi:/ showed me the following:
--------------------------------------------------------------
 l version='1.0' encoding='utf-8'?>
search status preferences help about
Strigi Desktop Search
Documents in queue 0
  Documents indexed 0
  Index size 0 MB
  Status idling
  Unique words indexed 6089
  Stop daemon
Start indexing
--------------------------------------------------------------

after a while strigidaemon stops or crashes and the cpu idles, starting the daemon again from strigi:/ works but causes high cpu-load for a while. After a minute or two the daemon is gone again..

After a reboot the crash-handler shows up, telling me that stringidaemon had crashed, but can't gather any information on that.

summary:
* high cpu-load while doing nothing
* crashes after a while
* " l version='1.0' encoding='utf-8'?>" in strigi:/

strigidaemon version: 0.5.1svn20070712-0ubuntu4

[Luka Renko (lure)]

I can confirm this on my system. Will try to build debug version and try to reproduce.

[steavieleeking (steavieleeking)]

the same here, on amd64 kubuntu gutsy.
top command shows 190 %CPU for strigidaemon and both cpu cores are 0.0%id
thats while indexing, if i leave the daemon doing nothing it takes 50% of each cpu cores.
as you can imagine while indexing the cpu gets really hot.

[Milan Knizek (knizek)]

The same for Gutsy Tribe 5 on x86 (generic kernel). Strigi has three processes (double core Intel M CPU), one is quite nice (19), the other two have normal priority. Two of the processes just eat all power. None seems to crash.

[Fred Hermanns (fintan)]

I can confirm this on Tribe5. Strigi also seems to crash konqueror and kmail. It starts up at boot with no way to edit this behavior.
At least removing strigi lets Konqueror and kmail behave stabily.

[Guillaume Pujol (guill-p)]

Same here on Gutsy.
Strigi successfully indexed all my files but keeps eating 100% CPU for some minutes, while strigi:/status report the daemon as idle:

Documents in queue 0
  Documents indexed 27934
  Index size 359 MB
  Status idling
  Unique words indexed 198042

if I strace the process while it's 100%, it just stays stuck in an 'accept()' function call.

$ strace -p `pidof strigidaemon`
Process 8522 attached - interrupt to quit
accept(7,

Regards,

[Guillaume Pujol (guill-p)]

About Fred comments:
Kmail and Konqueror both work fine here. Perhaps this is related to your CPU power, which can't handle both a 100% eating strigidaemon and the other apps (but I don't know which CPU you're using, so this is just an idea).
In my case I use a rather powerfull CPU with 2 cores (Core2Duo), so having one process at 100% on one of the core is not a problem, the other one handles the other process smoothly.

Regards,

[Luis Alberto Pabón (copong)]

Gillaume, I don't think such a shite CPU exists. Konq and KMail may very well appear to have frozen (and recover suddenly when strigidaemon dies) if the strigidaemon is drinking all the juice of the system.

In my case it doesn't, however this issue is a pain in the arse I have to say, I need to kill strigidaemon every single time I log in my computer. I just discovered my laptop reporting 101 degrees, which is rather unacceptable...

Other than that, seems to work and everything, has a large index and finds stuff on me HD.

[Vangelis Tasoulas (cyberang3l)]

I have the same problem here just after boot.
I did an strace as Guillaume mentioned before and I get the following output...

cyber@Aurora:~$ strace -p `pidof strigidaemon`
Process 5309 attached - interrupt to quit
accept(7, {sa_family=AF_FILE, path="��▒+"}, [2]) = 8
recvfrom(8, "g", 1, 0, NULL, NULL) = 1
recvfrom(8, "e", 1, 0, NULL, NULL) = 1
recvfrom(8, "t", 1, 0, NULL, NULL) = 1
recvfrom(8, "S", 1, 0, NULL, NULL) = 1
recvfrom(8, "t", 1, 0, NULL, NULL) = 1
recvfrom(8, "a", 1, 0, NULL, NULL) = 1
recvfrom(8, "t", 1, 0, NULL, NULL) = 1
recvfrom(8, "u", 1, 0, NULL, NULL) = 1
recvfrom(8, "s", 1, 0, NULL, NULL) = 1
recvfrom(8, "\n", 1, 0, NULL, NULL) = 1
recvfrom(8, "\n", 1, 0, NULL, NULL) = 1
gettimeofday({1190362758, 584057}, NULL) = 0
gettimeofday({1190362758, 584185}, NULL) = 0
open("/home/cyber/.strigi/clucene", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 60
fstat(60, {st_mode=S_IFDIR|0700, st_size=992, ...}) = 0
fcntl(60, F_SETFD, FD_CLOEXEC) = 0
getdents(60, /* 41 entries */, 4096) = 1296
stat("/home/cyber/.strigi/clucene/.", {st_mode=S_IFDIR|0700, st_size=992, ...}) = 0
stat("/home/cyber/.strigi/clucene/..", {st_mode=S_IFDIR|0700, st_size=200, ...}) = 0
stat("/home/cyber/.strigi/clucene/_ove.cfs", {st_mode=S_IFREG|0755, st_size=2108549, ...}) = 0
stat("/home/cyber/.strigi/clucene/_n5o.cfs", {st_mode=S_IFREG|0755, st_size=1204757, ...}) = 0
stat("/home/cyber/.strigi/clucene/_pq9.cfs", {st_mode=S_IFREG|0755, st_size=1455610, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qbu.cfs", {st_mode=S_IFREG|0755, st_size=159684, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qi0.cfs", {st_mode=S_IFREG|0755, st_size=169251, ...}) = 0
stat("/home/cyber/.strigi/clucene/_o0j.cfs", {st_mode=S_IFREG|0755, st_size=4374118, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qj8.cfs", {st_mode=S_IFREG|0755, st_size=60142, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qj8.del", {st_mode=S_IFREG|0755, st_size=10, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qex.cfs", {st_mode=S_IFREG|0755, st_size=144041, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qib.cfs", {st_mode=S_IFREG|0755, st_size=14850, ...}) = 0
stat("/home/cyber/.strigi/clucene/_ptc.cfs", {st_mode=S_IFREG|0755, st_size=123814, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qim.cfs", {st_mode=S_IFREG|0755, st_size=12279, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qjj.cfs", {st_mode=S_IFREG|0755, st_size=10453, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qjj.del", {st_mode=S_IFREG|0755, st_size=10, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qix.cfs", {st_mode=S_IFREG|0755, st_size=6312, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qiz.fdt", {st_mode=S_IFREG|0755, st_size=428, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qiz.fdx", {st_mode=S_IFREG|0755, st_size=8, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qiz.fnm", {st_mode=S_IFREG|0755, st_size=99, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qiz.frq", {st_mode=S_IFREG|0755, st_size=47, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qiz.prx", {st_mode=S_IFREG|0755, st_size=47, ...}) = 0
stat("/home/cyber/.strigi/clucene/_qiz.tii", {st_mode=S_IFREG|0755, st_size=31, ...}) = 0
stat("/home/cyber/.strigi/c...

[Paul-Sebastian Manole (brokenthorn)]

I can confirm this too except strigidaemon does not crash on my PC, just keeps running and using all my CPU for as long as forever :-/

It is though configurable through strigi:/ and restartable, after which it stops using the CPU at 100%.

I can't remove (since I don't really need such an application) because it's a dependency of kubuntu-desktop.

[Luka Renko (lure)]

Strigi packages are only Recommended by kubuntu-desktop, therefore you can safely remove them without removing kubuntu-desktop package.

[Ryan Zeigler (rzeigler)]

I observe the same behavior on my desktop computer that has lots of files, although, on my laptop, with few files, strigi starts up, and stays using 0% CPU.

[Shaved Wookie (shavedwookie)]

Basically the same here.

I just updated all packages today on my Kubuntu Gutsy and now I'm getting 60-90% CPU usage pretty much full time, even though daemon is reported as "Idling". Killing the strigidaemon and strigiapplet processes speeds things up dramatically.

  Documents in queue 0
  Documents indexed 33057
  Index size 149 MB
  Status idling
  Unique words indexed 344079

The strange thing is, that Xorg also seems to eat a lot more resources (40%-60% CPU while doing nothing), when Strigi's running.

[D. Brodzik (amyrose)]

I am also seeing this problem on the current Gutsy snapshot.

[Martin Gräßlin (ubuntu-martin-graesslin)]

Same for me:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25341 martin 18 0 105m 28m 3288 S 99 1.4 141:28.03 strigidaemon
14287 root 16 0 182m 110m 13m S 0 5.6 1:32.07 Xorg

I was surprised about the heat of my CPU, well strigi explains everything. I will remove it, as I do not need such a tool.

[goto (gotolaunchpad)]

I can confirm I am having this same problem as of 20070928 using Tribe 5(?) of Kubuntu. The fan was running all the time and the processor was maxed. When I looked to see what was pushing the processor so hard I found that strigidaemon was using over 98% of the CPU. I killed the processor and things went back to normal.

[Luis Alberto Pabón (copong)]

You killed the processor!? What with, an axe??

On 28/09/2007, bugmenot <email address hidden> wrote:
>
> I can confirm I am having this same problem as of 20070928 using Tribe
> 5(?) of Kubuntu. The fan was running all the time and the processor was
> maxed. When I looked to see what was pushing the processor so hard I
> found that strigidaemon was using over 98% of the CPU. I killed the
> processor and things went back to normal.
>
> --
> strigidaemon causes 100% CPU and crashes after a while
> https://bugs.launchpad.net/bugs/128876
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Luis Pabón

[Vangelis Tasoulas (cyberang3l)]

Upgrade from feisty to gutsy on my main machine and I have the same problem using strigi...

100% CPU Usage until I press the "Start indexing" that crashes it.

[Dorian Pula (dorian-pula-deactivatedaccount)]

Same here, with the upgrade from feisty to gutsy.
Originally, I thought that poppler-utils specifically pdftotext was causing the 100% CPU usage. But after a second look, I don't think that this is the problem.

[Shaved Wookie (shavedwookie)]

Worth considering... (from the comment at https://bugs.launchpad.net/ubuntu/+source/strigi/+bug/137753/comments/2)

"by default, strigi also indexes ~/.strigi..."

[Shaved Wookie (shavedwookie)]

One of my systems reports this when strigidaemon is started from CLI:
WARNING: field "TODO_tracknumber" is not define in .fieldproperties ontology database.
WARNING: field "TODO_discnumber" is not define in .fieldproperties ontology database.
Segmentation fault.

[Paul-Sebastian Manole (brokenthorn)]

Mem: 1035636k total, 1014148k used, 21488k free, 97120k buffers
Swap: 1951888k total, 34692k used, 1917196k free, 569292k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6420 thorns 18 0 52600 8624 3092 S 30.0 0.8 22:09.58 strigidaemon
6814 thorns 15 0 152m 53m 28m S 4.8 5.3 5:24.95 amarokapp

Has it been fixed?! That's just a small burst for strigidaemon now but it's small now in general.
My personal opinion is that strigi has been included by default for users to test it and report bugs but I personally don't want it installed.
Can it at least not be made a dependency of kubuntu-desktop so I and everyone else can more safely remove it?

[David Miller (djmdave)]

Paul,

kubuntu-desktop only recomends strigi related stuff, so you can easily/safely un-install. (see above: https://bugs.launchpad.net/ubuntu/+source/strigi/+bug/128876/comments/10 and http://packages.ubuntu.com/gutsy/metapackages/kubuntu-desktop)

The Right Thing™ would be to try and fix this bug, instead of sweeping the problem under the rug. It would be a shame if kubuntu cant ship with desktop search. For me this is a showstopper of a bug.

If I was more experienced, I would love to be able to help solve this. :-(

[Shaved Wookie (shavedwookie)]

Well, even as "non-coders" we can all help fix this bug by writing the
most detailed accurate bug descriptions we can, providing hardware and
package info on our systems to find commonalities and including
appropriate logs / crash reports / and other output info.

For example, is this a Kubuntu only error, or does it also occur where
people have installed Strigi on Gnome systems? It would be very hard
to guess from the comments on this bug so far. If they all listed
their System specs though...

Anyway, just the fact that we've all added to this bug report is a
step in the right direction. Now let's give Knusperfrosch all the help
we can to make it easy to get this fixed, patched and on our systems!
:)

On 10/2/07, David Miller <email address hidden> wrote:
> Paul,
>
> kubuntu-desktop only recomends strigi related stuff, so you can
> easily/safely un-install. (see above:
> https://bugs.launchpad.net/ubuntu/+source/strigi/+bug/128876/comments/10
> and http://packages.ubuntu.com/gutsy/metapackages/kubuntu-desktop)
>
> The Right Thing™ would be to try and fix this bug, instead of sweeping
> the problem under the rug. It would be a shame if kubuntu cant ship with
> desktop search. For me this is a showstopper of a bug.
>
> If I was more experienced, I would love to be able to help solve this.
> :-(
>
> --
> strigidaemon causes 100% CPU and crashes after a while
> https://bugs.launchpad.net/bugs/128876
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Guillaume Pujol (guill-p)]

Same behaviour in strigi-daemon 0.5.5-2ubuntu2 :(

[Aladiah (aladiah-89)]

I guess that it is because it is indexing information, then when you search through this applet, then it will show that required information, the only you can do is stop the daemon, by killing the process, then open the configuration, preferences and stop daemon, it had works fine for me until now

[Alberto Valero (valero)]

I believe that there is just a bug. The CPU load is too high for an
indexing daemon. If you compare it with Tracker or Google desktop on the
same PC you will see that these ones are much more lighter.

Hope that the stable release of Kubuntu 7.10 fixes it. Anyway tracker
works goot, aso in KDE.

[Ryan Zeigler (rzeigler)]

For me, I have discovered that strigi crashes if it is hung in the way described and start indexing is called. I attached a core file of that crash in the hope it will be useful.

[Dorian Pula (dorian-pula-deactivatedaccount)]

Upgraded strigi-daemon to 0.5.6-0ubuntu1. Strigi no longer takes up 100% CPU, instead it crashes a while after starting indexing. Basically after I updated this morning, I deleted .strigi/ and tried to index again. Strigi crashes continually after the first 200 documents indexed.

[Vangelis Tasoulas (cyberang3l)]

For me it is not crashing after the update, but is is indexing even if its status shows that it is idle and I am still able to click on Start Indexing.
Also it consumes 100% of my CPU while indexing.

[Stephan Wienczny (stephan-wienczny)]

The problem is still there with version 0.5.6-0ubuntu1. This bug renders kubuntu unusable with laptops because it drains the battery.

[David Miller (djmdave)]

strigi 0.5.6-0ubuntu1, it is no longer crashing, but the cpu usage during indexing bug is still there.

now i observe that strigi only uses 100% cpu when indexing, and then drops back down once strigi:/status reports its idling. before high cpu usage would continue even after indexing was complete.

attached is the output of strigidaemon when run from a shell. I've included a couple of comments which should be easy to spot.

also if it helps: I'm using gutsy with all updates, on a system upgraded from a clean fiesty install

[Adric Riedel (adric-riedel)]

My system has been running for seven hours now, and every three minutes or so it suddenly goes into VERY heavy load (70% CPU; I've even seen 99%) while Strigi does... something.

I never seem to get more than one or two minutes of no load.

[Ryan Zeigler (rzeigler)]

Behavior has changed on my system as of 10/16. Strigi no longer appears to hang, it successfully indexes close to 40x more files than it did previously (which I'm assuming is everything in the index directories) , and then goes into idling mode, and the CPU usage apparently goes to 0. Then, randomly for no reason the CPU usage went back up again later.

[Ryan Zeigler (rzeigler)]

The daemon also responds to the Stop daemon button now.

[Ryan Zeigler (rzeigler)]

Sorry for comment spam, but here, an hour later, strigi went into idle mode and has stayed there for 15 minutes, using 0 cpu time.

[René Vangsgaard (rene-vangsgaard)]

Kubuntu 7.10 64 bit on Asus V1S. The same problem here , Strigi uses between 50 and 100% on a Core 2 Duo. even though it says it is idling. And it has been running for 5 workdays.

Please note this bug as well https://bugs.launchpad.net/ubuntu/+source/strigi/+bug/157343.

[P (p92)]

In gutsy the daemon use 100% cpu after kde starts. Each time I have to go to the web interface and click on STOP. Then the daemon pass stopping and the cpu goes quiet.
strigi-daemon 0.5.6-0ubuntu1

[Hans van den Bogert (hbogert)]

it's still not working
I hate to kill the daemon everytime I boot my pc! Will there be a solution in the near future?

[aexl (aexl)]

just upgraded to kubuntu gutsy.
same thing here, strigidaemon eats my cpu.

[Michael Priest (pingers)]

Experiencing the same on Kubuntu 7.10.

Currently up to 6mins of near 100% cpu time on a core 2 duo system.

[Bèr Kessels (berkes) (ber)]

Still happening on Kubuntu hardy 8.04, running vanilla kde3.5. deamin ois NOT indexing ATM

top:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 6211 ber 20 0 118m 64m 3312 S 51.9 12.9 52:28.66 strigidaemon

strigi:/status
  Documents in queue 0
  Documents indexed 292814
  Index size 1562 MB
  Status idling
  Unique words indexed 4010325

ber@penelope:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Celeron(R) CPU 3.20GHz
stepping : 9
cpu MHz : 3193.910
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc up pebs bts sync_rdtsc pni monitor ds_cpl tm2 cid cx16 xtpr lahf_lm
bogomips : 6395.95
clflush size : 64

ber@penelope:~$ uname -r
2.6.24-17-generic

ber@penelope:~$ lsmod (is large, hence attached)

Hope this helps a developer. If more info is needed please ask me and I will try to help and provide.

[markoloka (markoloka)]

Same problem here + my strigi folder size is 3.6gb!!!!!!!!!!!
More here about fat strigi folder: https://bugs.launchpad.net/ubuntu/+source/strigi/+bug/227280
Can i remove safely such a program that is eating my cpu, ram and home folder usage?? I don't even use it.
Btw: Kubuntu 8.04 w/ 3.5.9 kde.
Free disk space now 82mb out of 9.2gb (100% used).

[Shaved Wookie (shavedwookie)]

Careful....

From memory I tried uninstalling it and adept uninstalled my entire
kubuntu-desktop (ie lot's of *important* packages). If you do choose to
uninstall, make sure you click on the "Preview" button in Adept Manager
before you click on "Apply" so you can see which packages it's about ot
uninstall. There should be no more than about 4-5. If you see a list of 20+
packages about to be uninstalled DON'T DO IT!

Trust me, I learnt this the hard way... =:-O

[[e-mail] (tarahwheeler)]

I've got a Core 2 Duo, and strigidaemon is eating 49% of system resources (I'm guessing that means it's hanging one core completely). What do I do? pdftotext is also zombie-fied.

[humufr (humufr-deactivatedaccount)]

Don't use strigi on ubuntu. The backend, redland, is obsolete and won't be change for intrepid for sesame2. And so strigi is taking forever to index a large disk with a lot of cpu time...

[aexl (aexl)]

semm to have this problem on kubuntu intrepid.
changing importance to: pain in the ass.

[Jonathan Thomas (echidnaman)]

This particular crash shouldn't be a problem in more recent versions of Kubuntu.