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: http://www.gnome.org/~michael/activity.html#2004-05-26 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: Always Steps to Reproduce: 1. Use laptop on battery 2. updatedb is triggered 3. A lot of battery life is lost Additional info:
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; fi [... test also /proc/apmd?? ] return 1; }
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.
And suspend support, and resume support, and... I'd rather tackle the whole shebang.
*** Bug 134842 has been marked as a duplicate of this bug. ***
OK, I'll put a fix to implement this into the next release.
Has this issue been resolved or has anything been done to improve the situation?
No idea... I'll just note that the new upstream release of apmd contains on_ac_power that already supports ACPI.
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. #!/bin/sh # Check if we are on batteries function is_on_battery { ON_BATTERY=-1 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 ON_BATTERY=0 fi fi else # 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 ON_BATTERY=0 fi done fi fi return ${ON_BATTERY} } if is_on_battery ; then echo "Is on battery" else echo "Is not on battery" fi
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.)
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?
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, agreed. 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: http://www.xs4all.nl/~bsamwel/laptop_mode/tools/ Or SuSE:s scripts for laptops: http://www.dr-k.de/D600/SuSE9.0/acpid_proxy 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 steps.
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.
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.
This should be reassigned to FC4 testing as I have said earlier.
*** Bug 157038 has been marked as a duplicate of this bug. ***
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.
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.
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.
*** Bug 157040 has been marked as a duplicate of this bug. ***
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 interval. 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 .
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 them.
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.
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.
*** This bug has been marked as a duplicate of 190268 ***