Bug 125779 - stop updatedb swallowing laptop battery when not on AC power
Summary: stop updatedb swallowing laptop battery when not on AC power
Status: CLOSED DUPLICATE of bug 190268
Alias: None
Product: Fedora
Classification: Fedora
Component: crontabs
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact:
: 134842 157038 157040 (view as bug list)
Depends On:
Blocks: 75781 FC3Target
TreeView+ depends on / blocked
Reported: 2004-06-11 12:44 UTC by albert vilella
Modified: 2007-11-30 22:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2007-08-14 10:42:08 UTC

Attachments (Terms of Use)
Extend on_ac_power for ACPI (732 bytes, patch)
2004-09-15 14:56 UTC, Miloslav Trmač
no flags Details | Diff
Patch that stops cron scripts from running when on battery power (732 bytes, patch)
2005-05-09 13:22 UTC, Linus Walleij
no flags Details | Diff

Description albert vilella 2004-06-11 12:44:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
I would like to have something similar SuSE seems to have for laptops:


A condition in the cron jobs so that updatedb is not triggered if the
laptop is running on the battery.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use laptop on battery
2. updatedb is triggered
3. A lot of battery life is lost

Additional info:

Comment 1 Florian La Roche 2004-09-15 14:08:13 UTC
Maybe something could be put into the initscripts that tries to
find out if we are on battery mode that could be added to some
more scripts?
(slocate, prelink, any more??)

is_on_battery() {
  if grep off-line /proc/acpi/ac_adapter/AC/state >/dev/null 2>&1 ; then
    return 0;
  [... test also /proc/apmd?? ]
  return 1;

Comment 2 Miloslav Trmač 2004-09-15 14:56:11 UTC
Created attachment 103864 [details]
Extend on_ac_power for ACPI

That should be at least
if ! [ -f /proc/acpi/ac_adapter/AC/state ] || grep ... 

apmd already has /usr/bin/on_ac_power, we could just extend that
script (bug 125561), e.g. like this, and move it to initscripts.

Comment 3 Bill Nottingham 2004-09-15 17:02:42 UTC
And suspend support, and resume support, and...

I'd rather tackle the whole shebang.

Comment 4 Jason Vas Dias 2004-10-06 18:55:41 UTC
*** Bug 134842 has been marked as a duplicate of this bug. ***

Comment 5 Jason Vas Dias 2004-10-06 18:59:42 UTC
OK, I'll put a fix to implement this into the next release. 

Comment 6 Linus Walleij 2005-02-21 12:48:46 UTC
Has this issue been resolved or has anything been done to improve the

Comment 7 Miloslav Trmač 2005-02-21 12:53:16 UTC
No idea... I'll just note that the new upstream release of apmd contains
on_ac_power that already supports ACPI.

Comment 8 Linus Walleij 2005-02-21 14:03:17 UTC
This script Simply Works (TM) please put it properly into /usr/bin/run-parts 
or atleast into /etc/cron.daily/slocate.cron. As you can see, it will survive
even the situation when apmd or its scripts are not installed. Thanks for 
your attention.

# Check if we are on batteries
function is_on_battery {
    if [ -f /proc/apm ] ; then
	# Check for this handy apmd script
	if [ -f /usr/bin/on_ac_power ] ; then
	    if /usr/bin/on_ac_power >/dev/null 2>&1 ; then
	# Else try with some ACPI specific code
	if [ -d /proc/acpi/ac_adapter ] ; then
	    AC_ADAPTERS=`echo /proc/acpi/ac_adapter/*`
	    for ADAPTER in ${AC_ADAPTERS}; do
	    # echo "Checking adapter ${ADAPTER}/state";
		if grep off-line ${ADAPTER}/state >/dev/null 2>&1 ; then
    return ${ON_BATTERY}

if is_on_battery ; then
    echo "Is on battery"
    echo "Is not on battery"

Comment 9 Linus Walleij 2005-03-07 14:58:02 UTC
Could someone move this to devel since it is still in there, and 
if I could I would change it from "enhancement" to a bug proper 
because it is. A most irritating one for laptop users. Perhaps you
could even bump it up to high priority because there is a very
simple fix for this problem, just fix it! (I can do a patch if you
really need that.)

Comment 10 Miloslav Trmač 2005-03-07 15:28:23 UTC
This code simply doesn't belong in slocate.cron; I still think that using
the existing on_ac_power is the best solution.

Bill, what suspend/resume support are you talking about in comment #3?

Comment 11 Linus Walleij 2005-03-07 15:40:16 UTC
OK if "on_ac_power" is still in the apmd package it cannot be used
until moved into a more general package (initscripts). It is easy to
modify "run-parts" to account for "on_ac_power" once that is in place,

Thing is, that since nothing has happened since 2004-06-11, I propose
that if moving that script is so hard, can we please have an interrim
fix as outlined above so that FC4 doesn't have to come out with this 
bug still in, while we are gloriously awaiting The Perfect Solution?

Also: could it be that Bill is fishing for something along the lines
of Debians laptop-mode-tools:
Or SuSE:s scripts for laptops:

Actually Fedoras support for laptops is in a sad state as of now :-(
Let's start improve it! This one simple thing is one of the first

Comment 12 Bill Nottingham 2005-03-07 17:48:19 UTC
A single unified framework for APM/ACPI/PMU, etc. From a brief glance, that SuSE
script certainly doesn't count. Would have to look at the debian code.

Comment 13 Matthew Miller 2005-04-26 16:31:31 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 14 Linus Walleij 2005-04-26 16:56:54 UTC
This should be reassigned to FC4 testing as I have said earlier.

Comment 15 Ivana Varekova 2005-05-09 10:55:44 UTC
*** Bug 157038 has been marked as a duplicate of this bug. ***

Comment 16 Linus Walleij 2005-05-09 13:22:29 UTC
Created attachment 114155 [details]
Patch that stops cron scripts from running when on battery power

This patch stops run-parts from running when on battery power.
I suggest it is added until a better, more general or whatever
solution is available. Please, this does not break anything or
create any dependencies, so use it until you decide how to handle
this some other way.

Comment 17 Bryan W Clark 2005-05-09 13:43:45 UTC
HAL has battery / AC support built into the latest version, perhaps it would be
easier to use a dbus-send command querying HAL instead of going after /proc
directly.  I'm adding david z to this since he'd know the interface options.

Comment 18 Miloslav Trmač 2005-05-09 14:03:36 UTC
on_ac_power is now in pm-utils (not apmd), and it does query HAL, so it could
be used 

But I don't think we can just stop run-parts like this:
- updatedb/makewhatis/yum wouldn't run at all that day.  Not applying updates
  daily even though the user explicitly enabled them is not very good.
- Similarly, it seems conterintuitive for /etc/cron.hourly to suddenly
  change its meaning from "hourly" to "hourly if on AC".

I think we have to separate "run-always" tasks from "maintenance" tasks that can
be postponed for a bit; but we're already frozen for FC4 now.

Comment 19 Jason Vas Dias 2005-05-17 22:28:55 UTC
*** Bug 157040 has been marked as a duplicate of this bug. ***

Comment 20 Jason Vas Dias 2005-05-17 22:53:38 UTC
I agree with Comment #18 . People need to be able to depend on 
the run-parts scripts running, regardless of the battery state.

It should not be the default behaviour of run-parts to be disabled
by the battery status.

This is the key issue here, not the plethora of ways to determine
the AC status .

If people want to disable run-parts while on battery power, then
it is simple enough to do "service cron stop; service anacron stop";
you could actually put these commands into an APM script.

I think that's actually simpler than editing some configuration file
to set a variable to say "don't run run-parts if on AC power".

People are free to add scripts like the one attached to run-parts 
or to the APM scripts - that's the beauty of open-source. But I 
don't think this should be the default behaviour for all users, who
should be able to depend on these scripts running at a fixed periodic

I think this issue can only really be handled effectively when we
have a configuration GUI to administer cron, and when cron and 
anacron co-operate (or anacron is replaced by cron), both issues
that I am working on for FC5 .

Comment 22 Jason Vas Dias 2005-05-17 23:45:57 UTC
I agree wholeheartedly with the last comment.

For "configuration GUI" in my previous comment, read "configuration
system" - for instance, cron could receive and react to events sent
by some configuration management system component telling it that
"we're on battery power / showing a movie and the user has chosen
not to run cron jobs now." .

It should NOT be the default that cron, run-parts, or anacron should
decide on the basis of lack of AC power and / or some text file
variable that it's not going to run a cron job. 

Whatever makes that decision has to be informed that:
 - we're not on AC power
 - the user does not want to run cron jobs while not on AC power
 - the user has been informed about or doesn't want to know that
   we're not running the cron jobs and has allowed us not to run 

Comment 23 Bryan W Clark 2005-05-18 04:59:49 UTC
I think in the generic sense I agree that you probably don't want to
mix up the meaning of cron.hourly with while(!on_ac_power) cron.hourly; 

However I think when you look at the individual applications (which
may be run by a script from cron) the picture is different.  Be it a
disconnected laptop or a server that has lost power and is on battery
backup you don't every really need a regeneration of your man pages. 
Similarly you'd need to regenerate the find database at a time like
this.  Prelinking is the same issue.  When laptops are on battery it's
just unnecessary to run those apps.  When servers have lost power, the
last thing you want those battery resources going to is man pages,
find databases, or prelinking.

Back to the generic case.  If server admins had put "backup-data.sh"
in the cron.hourly then I absolutely agree that you don't want the
battery status to interupt that job.  Cron.hourly should be hourly as
it suggests, however the programs I believe we're looking at should be
taken on a case by case basis.

Comment 24 Miloslav Trmač 2005-05-18 05:09:49 UTC
This should be easy to solve - just create /etc/maint.{daily,weekly}
with semantics "like /etc/cron.*, but the task may be delayed or
not run on a bad day".  Most of the cron tasks (with some exceptions,
e.g. yum) in Fedora's packages would be installed in /etc/maint.*,
while keeping the usual semantics for /etc/cron.*.

This takes care of the "which tasks" policy; the mechanism to run
these tasks and the policy when to run them is a separate question.

Comment 25 Marcela Mašláňová 2007-08-14 10:42:08 UTC

*** This bug has been marked as a duplicate of 190268 ***

Note You need to log in before you can comment on or make changes to this bug.