ThinkPad, Fn-F4 leads to double unsuspend

I have experienced this bug but I am now unable to reproduce it.

I can reproduce it ;)

Whereas, I haven't seen it for a long time. Mmmm, I hate bugs like this.

I experience this also.

It's probably becase the event triggered by pressing Fn-F4 doesn't reach acpid until the laptop resumes. Of course, when acpid gets that signal, it goes into suspend mode...

Yup, my theory seems to be accurate. The obvious workaround is to set the BIOS to not put the laptop in suspend mode when pushing the button, but rather leave this to acpid, but some sort of logic in the sleepbtn.sh script that could handle this would also be nice.

The BIOS isn't doing that.

No, I just figured that out too..

I can see that /etc/acpi/sleep.sh is called twice. I put in the following snippet:
---
echo "#################" >> /tmp/acpid
echo "PPID: $PPID" >> /tmp/acpid
ps -ef >> /tmp/acpid
---

I'll upload the file here (I removed some unrelated bits)..

It looks as though the call tree for the first one is:
gdm -> "pmi action sleep" -> "sleep.sh force"

hald -> hald-runner -> hal-system-power-suspend -> "pmi action suspend force" -> "sleep.sh force"

Now, the later makes sense to me, but the former doesn't. Why would gdm call "pmi action sleep"?

See previous comment for details

Ah... Here's probably why:
SuspendCommand=/usr/sbin/pmi action sleep

Hmm... So probably there's two solutions:
1. Put some logic into sleep.sh (prepare.sh already creates /var/lock/acpisleep, but nothing seems to check for the existence of this file AFAICS)

2. Make gdm back off when it's not "active" (ie. when it's not showing the login screen".

I've removed the naïve "touch /var/lock/acpisleep" from /etc/acpi/prepare.sh, and put this in instead:

if [ -f /var/lock/acpisleep ]
then
    exit 0
else
    touch /var/lock/acpisleep
fi

It stops two things trying to put the machine to sleep at the same time.

There's still the off chance of a race condition, but I can't really think of a safer way to do this in a shell script at this time of night. :-)

I was have having this problem on a T43, and it was reproducable 90% of the time. Soren's modification to prepare.sh seems to have resolved the problem for me.

I still have this problem. The acpi's scripts infrastructure has changed a little bit (/etc/acpi/prepare.sh linked to /etc/acpi/suspend.d/*).

I had this kind of problem with Breezy. The problems begun when I wanted to use my power button to hibernate the machine and lid close event to suspend.
I did this by linking the actions in /etc/acpi to new destinations. Powerbutton pointed to hibernate and lid to sleep (sorry but I can't remember the exact files).

All was working fine until I first pressed the power button to get the machine to sleep and then shut the lid while it was still performing the hibernate action.
After I resumed the session the machine immediately went to sleep.

Seems like all of these scripts should check if the machine is entering a powersaving mode before commencing another one. Who knows what crazy ideas the users will have ;-)

Is there any process (apart from the acpi shell scripts) that checks if /var/lock/acpisleep exists ?

If not, then I guess that Soren's patch is necessary.

What about it for Edgy ?

An answer to my last question is necessary. However, I have not experienced the double suspend bug at all since I use Edgy (few months).

I confirm the problem I mentioned in bug #43606 does not exist in Edgy. It appears acpid itself checks for the existence of /var/lock/acpisleep and does not process events if this file exists. This is consistent with a comment in the acpi scripts at the point where this file is created. So I believe that this line of bugs is fixed and can be closed.

This patch of the 15th of september against acpid effectively introduces a check on /var/lock/acpisleep.

https://patches.ubuntu.com/a/acpid/acpid_1.0.4-5ubuntu4.patch

It would be useful to consider backporting it to dapper.

I'm seeing exactly this behaviour now, 3 years later. Also on a Thinkpad... T400. Has something reverted?

I suggest filing a new bug report for the issue you're seeing, since acpi-support no longer handles the Fn+F4 key at all. Please use 'ubuntu-bug pm-utils' to report this new problem, and include the output of 'acpi_listen' run from a terminal during the suspend/resume.