acpi scripts are only called on events

[Martijn de Nerd]

Binary package hint: acpi-support

Scripts in /etc/acpi/battery.d or /etc/acpi/ac.d are nicely called when I plug or unplug my powersupply. However, at boottime or when resuming from suspend, these scripts aren't called. This means that my laptop doesn't notice when I unplug during suspend-to-ram, or even worse; when I boot without power plugged, it doesn't start all my save-as-much-power-as-possible-scripts.

I think that after resume and boot, the powerstate should be checked again and scripts should be started accordingly.

[Peter Whittaker (pwwnow)]

Martin, have you modified /etc/default/acpi-support to set ENABLE_LAPTOP_MODE to true?

From reading the various related scripts in /etc/init.d/, /etc/acpi/, and elsewhere, it seems there are inconsistencies with how and when the relevant commands are invoked. But I want to make sure the machine is configured correctly before proceeding. Thanks!

[Vadi (vidar314)]

Peter, I can confirm I have set ENABLE_LAPTOP_MODE to true, and the problem still persists.

[Martijn de Nerd (martijn-de-nerd)]

The ENABLE_LAPTOP_MODE switch doesn't seem to influence the calling of the scripts. Setting it true, it still ignores the scripts in ac.d and batt at boottime or after resume.

[msrgi (mysergi)]

Hi folks,

I've solved (?) the problem by modifying /etc/acpi/power.sh:

 if [ x$1 != xenforce ]; then
        checkStateChanged;
fi

and resume.sh will then call

power.sh enforce

at the end.

[Martijn de Nerd (martijn-de-nerd)]

i'd love to try it, but i don't get it. could you be more precise about what to add where?

tnx!

[Peter Whittaker (pwwnow)]

I'm marking this as confirmed, as this is a problem, but it could just as easily be marked rejected (more or less working by design), because the underlying design is problematic. Of course rejecting it would simultaneously require a blueprint be opened to cover the following....

The problem is that we have multiple conflicting ACPI event management tools on laptops. The proper set includes HAL and PMI, which are used by Gnome (comments about limited power management capabilities in gnome withheld), and these apply to all machines.

The conflicting set is laptop-mode tools and various ACPI event scripts, which - by design - are not used when Gnome is running (scripts contain checks to silently exit and let Gnome handle policy).

This is counter to what the user expects. The correct things to do are all of:

a) provide script-level PMI controls so that users can suspend/resume/etc. from scripts if they so choose,

b) remove the laptop-mode and other tools obsoleted by PMI and its brethren, and

c) give Gnome more configurability, so users can make their machines behave as expected.

That's a lot for one report. Unfortunately, I am no longer able to triage, so that's the best I can do with this. Hopefully someone else can pick this up and make the right things happen.

[Valentin Neacsu (valentin.neacsu)]

I'm experiencing the same problem with a Dell Inspiron 6400/E1505 (where scripts don't get executed on reboot on battery or resume), and on a Dell Latitude D630 (scripts DO get executed when booting on battery, but don't get executed on resume).

Can anyone tell me how I can manually send (fake) events to acpid? This is because, unless current and last power state differ, scripts won't be called, even though I can see in /var/lib/acpi-support/powerstate that I'm running on BATTERY. I can manually execute all the proper scripts when on battery, but that doesn't activate everything necessary on the Dell Latitude D630.

[Valentin Neacsu (valentin.neacsu)]

I've managed to trick Ubuntu 7.10 to activate batttery mode (laptop mode and all the scripts) by doing this

$ gedit battery.sh

--- cut here ---

sudo su -c "echo AC > /var/lib/acpi-support/powerstate"
sudo /etc/acpi/power.sh
sudo su -c "echo BATTERY > /var/lib/acpi-support/powerstate"

--- cut here ---

save & exit

$ chmod +x battery.sh

Now every time I know I'm running on battery and Ubuntu doesn't sense it and so it's draining way too much current I run

$ ./battery.sh

I don't know how clean this is, but this is the best thing I could do.

I'd like to trick acpi-support into thinking I plugged in and out the AC adapter by sending a fake ACPI event, but I currently don't know how to do that.

[Valentin Neacsu (valentin.neacsu)]

Okay scrap what I said earlier.

I read msrgi's fix and it does work. I'll post clearer instructions on how to do it.

Open a terminal (Accessories -> Terminal) and type:

sudo gedit /etc/acpi/power.sh

(you can replace gedit with your favourite text editor). It will ask for your password so type it.
Scroll down to line 38 where you'll find:

checkStateChanged;

Change that so it looks like this:

if [ x$1 != xenforce ]; then
        checkStateChanged;
fi

Now save and close gedit. In your terminal window type this:

sudo gedit /etc/acpi/resume.sh

Scroll down to the last line and add this on a new line so that it is the last line in the file:

/etc/acpi/power.sh enforce

Save and close gedit. In your terminal window type this:

sudo gedit /etc/rc.local

Scroll to the end and add this *before* the last line (before the "exit 0" line):

# delay to allow acpi-support and gnome to load, in seconds
# increase if your laptop is not fast enough
sleep 60 && /usr/bin/on_ac_power;
if [ "$?" -eq 1 ]; then
    /etc/acpi/power.sh enforce
fi

Save and close gedit. Reboot.

After these modifications, scripts are called even if you suspend/hibernate on battery and resume on AC and vice-versa, and even if you boot on battery. I don't really understand what msrgi's fix does and how it works, but it works.

[Valentin Neacsu (valentin.neacsu)]

The same problem still exists in Hardy. The fix above doesn't work any more :(

[mannheim (kronheim)]

This is the situation in intrepid, I think:

The script /etc/acpi/power.sh seems to be called whenever the AC power is plugged in or removed, and it is also called at boot up (via the init script /etc/init.d/acpi-support) and when resuming from suspend. This is okay.

However, the script /etc/acpi/power.sh checks whether the power state has actually changed, using the function checkStateChanged(). This function does "exit 0" if the state has not changed. If the state has changed, then the power.sh script runs all the scripts in either /etc/acpi/battery.d or /etc/acpi/ac.d, as appropriate.

This works fine for plugging in and unplugging the power, and at resume from suspend. It does not work at boot time, however, because the checkStateChanged function is irrelevant at boot time. This is the thought behind msrgi's modification. I think a simpler way to deal with it is to change /etc/init.d/acpi-support by adding a line:

case "$1" in
  start)
    log_begin_msg "Checking battery state..."
    if [ -f "$POWERSTATE" ]; then rm "$POWERSTATE"; fi
    /etc/acpi/power.sh
   ...... etc ....

The result should be that the init script will always call the scripts in either /etc/acpi/battery.d or /etc/acpi/ac.d on startup.

[Steve Langasek (vorlon)]

I'm marking this bug as resolved because in the latest release of Ubuntu, acpi-support hands off all script handling to pm-utils. If there are any cases not yet handled correctly by pm-utils, this bug should be reopened and assigned there.