shouldn't queue a second suspend if the machine is already suspending

Potentially related issues:
https://bugzilla.redhat.com/show_bug.cgi?id=475585

https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/425411

https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/261084

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Confirming with latest version.

Confirmed this still affects 3.2.0-12.20.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

I can confirm this bug still exists when using pm-suspend from the command line to suspend the machine.

I'm seeing this behavior as well on a ThinkPad T400. I am running 12.04 LTS.

bfox@bfox-laptop:/lib/modules/3.2.0-35-generic$ uname -a
Linux bfox-laptop 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux

I can reproduce the problem pretty much at will. The double-suspend problem is quite annoying. Please let me know what I can do to help diagnose the problem further.

Also reproduces on a Latitude E5430 running 12.04.1. Same sequence of events:

1) Press Fn+F1 hotkey.
2) Close the lid immedately after pressing hotkeys.

Laptop suspends...

3) Open the lid the system appears to resume but then jumps right back into S3.

I can also verify the workarounds in that using just the lid or using the hotkeys and then waiting a few seconds before closing the lid prevents the system from going into a double-suspend state.

I can easily reproduce this problem with 12.04 on a thinkpad X200s

Can folks affected by this bug confirm whether or not this happens in Raring?

I think this has something to do with the way the way hotkeys are delivered as keyboard keys and lid close is treated as a signal in gnome-settings-daemon. You can reproduce this issue by selecting "Suspend" from the menu, and then closing the lid, but you can not reproduce by selecting "Suspend" and then hitting the hotkey. Similarly hitting the suspend hotkey or the suspend+hibernate hotkey quickly does not cause problem.

Also if you take a look at the solution to bug 261084 you can see that in the past this was solved by eating keyboard keys but that was never applied to the lid close signal.

This is not a bug but a feature. The user is asking to suspend the machine twice, so it is doing as it is told.

acpid just gets a bunch of events and handles them in a serialized fashion. Hence if a user presses the sleep button and then closes the lid, acpid will have 2 sets of suspend requests.

We may have the following:

sleep button --> event
lid --> event

acpid gets the 1st event and suspends the machine. It may be that the 2nd event is also being activated but the kernel freezes this before it kicks off a 2nd suspend. Once the machine resumes, we can be sure that the 2nd suspend event kicks in and hence we see the double suspend.

While I somewhat agree with @jsalisbury above, I'd like to note that I *cannot* reproduce this issue with Kubuntu 12.04 (kernel 3.5.0-25, KDE 4.10).

I wonder if people affected by this issue are using Unity or Gnome or what.

I will check with 12.04.2 on the same E5430 that I reproduced this on earlier.

This no longer reproduces on my Latitude E5430 running 12.04.2 using the 3.5.0-based lts-quantal kernels.

I can still reproduce this on 3.5 kernels.

@jsalisbury: You are correct in that the system is simply doing what it is told, but it's still a bug in the user experience.

The question is what the user is intending to do. Is the user intentionally telling the system to suspend twice? There's no use case in which that's useful.

Then we have to consider the user experience. When the user opens the lid, they are telling the system to wake up because they intend to use it. They aren't expecting the system to put itself back to sleep, so this violates the principle of least surprise.

Status changed to 'Confirmed' because the bug affects multiple users.

Could somebody upstream the GNOME bug against gnome-settings-daemon: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-settings-daemon ?

Unassigning the desktop team, we don't have currently anyone with spare cycles to look at that, and it seems really a minor issue: it's not easy to trigger the second suspend before the first one kicks in, and there is no breakage, just an annoyance that you need to resume a second time

If that's a real issue for oems please ping me to discuss it

Ryan agreed to talk to upstream/have a look to the issue, reassigning to him

Status changed to 'Confirmed' because the bug affects multiple users.

We fixed this issue in saucy by moving responsibility for handling suspend into systemd-shim and adding a check there to ignore suspend requests that come in during a very small window after waking up. From personal reports, this has solved the issue for everyone who has tried it.

I'm not totally happy with the solution -- I would prefer if we had one based on the timestamps of the source of the suspend (ie: clicking a menu item with the mouse, lid-close events, etc) and were able to compare that with the time of the suspend itself. This requires some changes to logind, though. This has been discussed with upstream and we're waiting.

Hi Ryan,

Can the same fix be applied to the equivalent packages in precise? If so, I will be requesting that we SRU these changes once upstream agrees to them.

hi James,

Unfortunately we handle suspend in a much more ad-hoc way on precise. There is no logind or systemd-shim through which all suspend requests are handled. These changes are therefore not really possible to backport.

Okay, thank you for that information.

Not critical enough to get in the OEM priority queue

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release