Closing lid during initial shutdown causes notebook to suspend

This just happened to me with Gutsy and KDE. I clicked "Turn Off" and closed the lid, and put my laptop in my bag--I've never had Kubuntu fail to shut down before. When I got home 20 minutes later, it had never shut down, and it was quite hot. Checking the acpid log shows that it executed the script for the lid event, and apparently shut down acpid, but the system did not shut down. The VTs were unresponsive, but I was able to use the SysRq key to make the kernel reboot.

In this log snippet, the button event was when I pressed the power button, after which I clicked "Turn Off". Then I closed the lid...

[Wed Apr 2 23:50:50 2008] completed event "button/power PBTN 00000080 00000005"
[Wed Apr 2 23:51:16 2008] received event "button/lid LID 00000080 00000003"
[Wed Apr 2 23:51:16 2008] notifying client 5664[107:116]
[Wed Apr 2 23:51:16 2008] notifying client 5739[0:0]
[Wed Apr 2 23:51:16 2008] notifying client 5739[0:0]
[Wed Apr 2 23:51:16 2008] executing action "/etc/acpi/lid.sh"
[Wed Apr 2 23:51:16 2008] BEGIN HANDLER MESSAGES
ERROR: Couldn't attach to DCOP server!
[Wed Apr 2 23:51:18 2008] END HANDLER MESSAGES
[Wed Apr 2 23:51:18 2008] action exited with status 1
[Wed Apr 2 23:51:18 2008] completed event "button/lid LID 00000080 00000003"
[Wed Apr 2 23:51:40 2008] exiting

This affects KDE too, not just gnome-session.

the bug is not a gnome-session one

Is this symptom still reproducible in 8.10 beta or later?

Marking it as fix released as I can't reproduce it in Intrepid.

It happens to me in Jaunty. I guess the fix is not released yet.

The acpi-support package doesn't implement suspending on lid close, it only handles screen locking; and in any case acpi-support's suspend handling is inactive when a desktop is detected. This must be a bug in the corresponding desktop event handlers.

I use Kubuntu; gnome-power-manager doesn't apply.

On Tue, Sep 8, 2009 at 19:31, Steve Langasek
<email address hidden> wrote:
> The acpi-support package doesn't implement suspending on lid close, it
> only handles screen locking; and in any case acpi-support's suspend
> handling is inactive when a desktop is detected.  This must be a bug in
> the corresponding desktop event handlers.
>
> ** Package changed: acpi-support (Ubuntu) => gnome-power-manager
> (Ubuntu)
>
> --
> Closing lid during initial shutdown causes notebook to suspend
> https://bugs.launchpad.net/bugs/138194
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I can reproduce this with karmic gnome.

After selecting "shutdown" a dialog appears with a 60 seconds countdown. Now i close the lid. Instead of shutting down, the laptop suspends now.
After pressing a key i enter my password, the screen is restored and the countdown continues. Ok, i could cancel the countdown to avoid the shutdown.

But this should behave differently: Shutdown->Countdown->Closing lid->no suspend, but shutdown after countdown, or maybe shutdown immediately.

can't reproduce in Lucid on my netbook

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

- I'm unable to reproduce this issue too on either Karmic or Lucid .
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

om26er: Do you have sleep on lid close enabled? This will only happen in those cases.

I think this MAY be easily resolved by inhibiting sleep via devicekit-power. In addition, we could have the shutdown countdown watch the org.freedesktop.DeviceKit.Power 'LidIsClosed' property and shut down immediately if that is set to True.

gnome-session's dialog has the exact same issue.

I will investigate this more closely right now :)

Dylan , thanks for pointing that out.
Seems i had changed the default to "blank screen" and wasnt facing this problem ;)

Do report back, if you believe this can be fixed easily. [marking this as incomplete as I'm not sure we have an easy/simple fix]

Has this issue been reported uptream? or is this an Ubuntu bug? [wondering why it wasnt sent upstream for nearly 2+yrs]

Hi again, Vish :)

The same usability issue strikes gnome-session's own dialogue, too. (You get that when you tap the power button). So, it is applicable upstream, but there are actually two separate projects. The most important one in our case is the downstream one triggered by indicator-applet-session.

The fix will lie in indicator-session/src/gtk-logout-helper, which is part of a separate program that indicator-session calls to trigger the log out, shutdown or restart dialog.

It will need to use Gnome Session Manager to inhibit sleeping, only uninhibiting when it wants to (when the dialog response is triggered). Other clients which inhibit the session will be respected, so it should be happy.

In theory, we could also watch the devicekit-power Changed signal, faking a dialog OK action when LidIsClosed becomes True. (Although this may be a Really Bad Idea for laptops with external displays, so perhaps best left for another patch).

The process of building this thing is making my head hurt; getting a head full of errors, basically for every line in indicator-session.c, with a fairly clean Karmic, the Karmic version of the sources and all of the build dependencies for the indicator-session package. Those errors have nothing to do with my changes, though. There's hope that it may actually work :)
If somebody can take a look at this and maybe build it, I'll be grateful. I'll try pushing this into a VM later.

As mentioned, a similar fix should also be applied in gnome-session. I'll start up a discussion upstream on this topic; I may be taking completely the wrong approach, after all.

this bug is fixed in Lucid

This is not fixed in Lucid on my system. Maybe we try different things.

If i press the power button (hardware) a dialog appears showing some options such as "shut down". On the bottom of the dialog there is a 60 second countdown running. Closing the lid while this countdown is running will suspend the system. After wakeup, the countdown is going on...

I'd like to see the Importance of this bug raised because of how ubiquitous laptops are. A user expecting a few hours of battery life might return to a completely dead laptop.

Also, a padded laptop bags can be good thermal insulators. As Adam Porter noted, laptops can get very very hot if they are left running in places that the user might store a shut-down laptop.

Isn't this a config option now?

When this bug was reported. I was able to reproduce this but now I dont see
it so luck? ;)

On Tue, Jul 6, 2010 at 12:28 PM, Rolf Leggewie <launchpad.net@
rolf.leggewie.biz> wrote:

> Isn't this a config option now?
>
> --
> Closing lid during initial shutdown causes notebook to suspend
> https://bugs.launchpad.net/bugs/138194
> You received this bug notification because you are subscribed to
> indicator-session in ubuntu.
>
> Status in The GNOME 2 Session Manager: Unknown
> Status in One Hundred Paper Cuts: Incomplete
> Status in “gnome-power-manager” package in Ubuntu: Invalid
> Status in “indicator-session” package in Ubuntu: Confirmed
>
> Bug description:
> Using the gnome shutdown button and closing the notebook lid immediately
> afterwards will cause the notebook to enter suspend rather than shutting it
> down. When lid is opened again, the notebook will continue to shutdown after
> the desktop is restored.
>
> Proposed fix: Either prohibit any go-to-suspend events after shutdown
> button has been pressed, or let lid-close events abort the shutdown
> sequence.
>
> Ubuntu version: newest gutsy
>
>
>

ofcourse the papercut task. :)

Dylan Mccall, the branch you had linked seems empty: lp:~dylanmccall/indicator-session/bug138194
Unlinking as there is nothing in it yet, are you working on the branch?

I think a solution to this would be to set a flag to a particular state when shutdown commences, which will then hold up all operations that attempt to execute, including suspend. On some versions of Windows, I've been presented with an error message when I try to do something when the shutdown button has been hit.

This would not be simple to implement, so this is not a paper cut.

I think it might be simple to implement. A patch to KDE's and GNOME's
session managers to touch a file in /var/run or somewhere, and a patch
to the suspend scripts to check for that file. Three small patches?
Four if you include LXde?

2011/1/16 Chris Wilson <email address hidden>:
> I think a solution to this would be to set a flag to a particular state
> when shutdown commences, which will then hold up all operations that
> attempt to execute, including suspend. On some versions of Windows, I've
> been presented with an error message when I try to do something when the
> shutdown button has been hit.
>
> This would not be simple to implement, so this is not a paper cut.
>
> ** Changed in: hundredpapercuts
>       Status: Incomplete => Invalid
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/138194
>
> Title:
>  Closing lid during initial shutdown causes notebook to suspend
>

This bug still occurs in Oneric daily. It's more prominent there because shutting down seems to take longer than ever before.

Could this be fixed by simply making the shutdown sequence kill FIRST the piece of code that watches for the lid to close?

Such "small" things as this bug makes Ubuntu user experience irritating. If I push the poweroff button and confirm my decision and I see the system is shutting down, I assume that I can safely close the lid and forget about my computer. But a few days later I see the led light blinking, power the system on and... what a surprise... system is continuing to shutdown. And I'm a lucky man if a battery will not shut down before this. It's a shame that such a primary (from user experience perspective) bug has five years old!
And yes, I have 12.04 LTS. And no, I will not install 12.10 just to test if it will be ok by some unknown magic.