Bug 332444 - Regression: baloo_file_extractor working while laptop is on battery, causing 100% load on multiple cores and thus draining the battery
Summary: Regression: baloo_file_extractor working while laptop is on battery, causing ...
Status: RESOLVED FIXED
Alias: None
Product: Baloo
Classification: Unclassified
Component: Baloo File Daemon (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Vishesh Handa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-22 15:11 UTC by Christian (Fuchs)
Modified: 2014-04-28 16:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian (Fuchs) 2014-03-22 15:11:05 UTC
With nepomuk the indexer(s) respected the current power state of devices, e.g. when a laptop was on battery, indexing stopped in order to have a decent battery life. 

I just unplugged my laptop and several baloo_file_extractor processes kept multiple cpu cores at 100% load, thus reducing the remaining battery time by about 75% 

Reproducible: Always

Steps to Reproduce:
1. Enable baloo indexing
2. Unplug your laptop from the power source
Actual Results:  
Processes keep running and causing 100% load for at least several minutes, heavily draining the battery

Expected Results:  
All indexing is suspended in order to preserve battery
Comment 1 Vishesh Handa 2014-04-07 11:05:56 UTC
It works correctly for me. This could have been the result of a bug which caused multiple baloo_file_extractor processes to be spawned. It has been fixed.

Otherwise the only reason that I can think of this happening is that if the extractor process is already running and then you move to battery, that process is not killed. Hmm, there can be another case as well. I'll look more into it.
Comment 2 Christian (Fuchs) 2014-04-07 12:16:22 UTC
(In reply to comment #1)
> It works correctly for me. This could have been the result of a bug which
> caused multiple baloo_file_extractor processes to be spawned. It has been
> fixed.

If you have a .diff for me  (or a pointer to the commit) I can check for you if I can reproduce it still with that.  Or I can check after the release  (which, I assume, contains the fix), as I don't know the release schedule by heart: if it can be fixed before the final tag, that would be nice of course, though. 

> Otherwise the only reason that I can think of this happening is that if the
> extractor process is already running and then you move to battery, that
> process is not killed. Hmm, there can be another case as well. I'll look
> more into it.

Unfortunately I don't have my notebook along, but I am 99% sure that the processes where already running before I unplugged the power, so that might very well be it. Are they supposed to be instantly killed? If not: it might be that they just kept running, as I have a couple of files which are huge  (basically zips containing a _huge_ load of xml log files) this might have been the case. 

Thanks for looking into it :)
Comment 3 Vishesh Handa 2014-04-28 16:20:28 UTC
Git commit 96acbfd180a95e1b935bcb3d382cfa0e68d3e4ed by Vishesh Handa.
Committed on 25/04/2014 at 15:26.
Pushed by vhanda into branch 'KDE/4.13'.

FileIndexingJob: Pause it when on battery

The FileIndexingJob normally just takes one iteration, except in the few
exceptional cases when there is an offending file. In those cases, we
try to call the extractor again with half those files, and keep
splitting until we find the offending file.

Normally, the file indexer is never run when on battery, so this patch
just makes sure the error detection code is not run when on battery and
the file indexer was already running.

M  +24   -3    src/file/fileindexingjob.cpp
M  +6    -0    src/file/fileindexingjob.h
M  +23   -5    src/file/fileindexingqueue.cpp
M  +5    -0    src/file/fileindexingqueue.h
M  +10   -0    src/file/indexingqueue.cpp
M  +2    -0    src/file/indexingqueue.h

http://commits.kde.org/baloo/96acbfd180a95e1b935bcb3d382cfa0e68d3e4ed