#590519 pm-utils: /var/log/pm-powersave.log grows rapidly

#590519#5
Date:
2010-07-26 23:41:13 UTC
From:
To:
A few days ago (hmmm, probably corresponding to a reboot to
2.6.32-5-amd64), my /var/log/pm-powersave.log started growing rapidly
with an entry per second of:

/usr/lib/pm-utils/power.d/sched-powersave false: **sched policy powersave OFF
success.


Not good for powersaving if it keeps the disk spun up and CPU churning
executing /usr/lib/pm-utils/power.d/sched-powersave all the time!

#590519#10
Date:
2010-07-26 23:51:43 UTC
From:
To:
pm-powersave should only be run, when you plug/unplug your ac adapater.
Did you repeatedly unplug power?
Do you get those messages when you don't change between battery and ac?
Try to monitor the log file with "tail -f /var/log/pm-powersave.log" please.

Michael

#590519#15
Date:
2010-07-27 00:04:28 UTC
From:
To:
Woops, I assumed the file was being rotated daily, and there are 3 large
pm-powersave.log files followed by 2 more small files with reasonable
amounts of log messages.  It turns out they're being rotated monthly, and
the large amount of logging started back in May.  I don't know what
specific package upgrade is at fault, I'm afraid.

No.

As I said, it grows at a rate of approx.  1 per second.

/usr/lib/pm-utils/power.d/sched-powersave false:**sched policy powersave OFF
success.
/usr/lib/pm-utils/power.d/sched-powersave false:**sched policy powersave OFF
success.

Over and over again.  So far, up to 117MB this month since last being
rotated.

There is a battery fault in this laptop (old battery, still holds some
charge, but causes the battery LED to blink red - perhaps causing excess
acpi messages, and getting pm-utils confused?  But the battery has been
in this state a lot longer than since this bug appeared).

This bug does not affect my other Dell laptop running 2.6.34-1.

(fortunate that this doesn't break my backup scheme, given that such
messages are extremely compressable).

#590519#20
Date:
2010-07-28 04:40:47 UTC
From:
To:
Turns out that the acpi scripts are/were crap, and just trigger pm-utils
on every battery event, as I suspected.

Apologies if this is all dealt with in an update of acpi-support (I
suspect I'm several versions behind in acpi, because I'm so reluctant to
upgrade it given that something different breaks everytime I upgrade - but
I shall attempt to test when I get home tonight).


If I modify
/etc/acpi/events/battery
and
/etc/acpi/events/ac

to include %e:

================================
# /etc/acpi/events/ac
# Called when the user connects ac power to us
#

event=ac_adapter.*
action=/etc/acpi/power.sh %e
================================

================================
# /etc/acpi/events/battery
# Called when AC power goes away and we switch to battery

event=battery.*
action=/etc/acpi/power.sh %e
================================

And /etc/acpi/power.sh is buggy in that $* is always != "", because $1 is
the name of the script, /etc/acpi/power.sh, and without %e, there are no
other parameters.

If I add a debug statement at the top of /etc/acpi/power.sh,

echo "`date`: /etc/acpi/power.sh $@" >> /tmp/test.log

I get the following:

Wed Jul 28 14:30:28 EST 2010: /etc/acpi/power.sh battery PNP0C0A:00 00000080 00000001
Wed Jul 28 14:30:29 EST 2010: /etc/acpi/power.sh battery PNP0C0A:00 00000080 00000001
Wed Jul 28 14:30:30 EST 2010: /etc/acpi/power.sh battery PNP0C0A:00 00000080 00000001
Wed Jul 28 14:30:32 EST 2010: /etc/acpi/power.sh battery PNP0C0A:00 00000080 00000001

I haven't investigated yet (I'll followup when I get home later today),
but that's probably a battery failure message.  I wouldn't be surprised if
ACPI has provision to log similar events if the ac adaptor were to detect
problems such as overheating or overload, but unforunately, power.sh just
unconditionally hands all battery.* and ac_adaptor.* messages onto
pm-powersave, which unconditionally changes the power mode and logs
messages without checking whether this is sane.

I don't know where this bug more belongs, pm-powersave, or acpi-support?
I suspect acpi-support for not actually passing anything onto the
script to identify what acpi event occurred.  But pm-powersave is going to
have to do something useful with that message.  For instance, I want to
log and act upon when ac/battery is turned off, but all I'm told is "true"
"false".  True/false what?  Elephants?

#590519#25
Date:
2023-12-21 17:56:09 UTC
From:
To:
Dear submitter,

as the package pm-utils has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1058701

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)