Notebook doesn't suspend when lid is closed after update to 16.04

Bug #1574120 reported by patrick70
630
This bug affects 135 people
Affects Status Importance Assigned to Milestone
pm-utils (Ubuntu)
Confirmed
Undecided
Unassigned
systemd (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

My notebook does not suspend after upgrading from 15.10 to 16.04.

According to system settings the notebook should suspend when lid is closed but actually this does not happen. Instead it continues to run as if nothing had happened.

With the previous versions of ubuntu (14.04-15.10) everything worked fine.

My System: HP Pavilion dv7.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: acpi (not installed)
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Apr 23 23:11:15 2016
InstallationDate: Installed on 2015-10-29 (176 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: acpi
UpgradeStatus: Upgraded to xenial on 2016-04-22 (1 days ago)

Revision history for this message
patrick70 (patrick70) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in acpi (Ubuntu):
status: New → Confirmed
Revision history for this message
dlh (dolohow) wrote :

Happens on my HP ProBook 640 G2 too.

Revision history for this message
Bruno Santos (bsantos) wrote :

Same thing on a HP Sleekbook 15

Revision history for this message
Bruno Santos (bsantos) wrote :

Adding HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf solved it in my system, but suspend was flawless before upgrading to 16.04.

Revision history for this message
patrick70 (patrick70) wrote :

I tried HandleLidSwitchDocked=suspend. After closing the lid the notebook appears to be half way suspended but the fan is still working. Worse: I could not get it to wake up again. Open the lid => nothing, pressing any key => nothing, pressing a mouse button => nothing.

When I suspend the notebook with the item in the system menu it gets into a similar state without any chance to wake it up again.

Revision history for this message
Betty (sturdyandserviceable) wrote :

This bug affects me on my HP Pavilion dv6, but adding HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf appears to have solved it.

Changed in acpi (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Pranav Sharma (sudopluto-deactivatedaccount) wrote :

I had this problem as well, and adding the "HandleLidSwitchDocked=suspend" fixed it. Why would Ubuntu think that the laptop is docked 24/7?

Revision history for this message
Carl (carl-leach-public-b) wrote :

Same issue on HP G62-105SA Notebook PC.

The lid state is correctly reported in /proc/acpi/button/lid/LID0/state

Revision history for this message
Carl (carl-leach-public-b) wrote :

Confirm that adding HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf solved issue on HP G62-105SA Notebook PC.

Revision history for this message
Richard Brooksby (rptb1) wrote :

Also affects my HP Stream 11.

Bruno Santos (bsantos)
affects: acpi (Ubuntu) → systemd (Ubuntu)
Revision history for this message
Bruno Santos (bsantos) wrote :

From https://www.freedesktop.org/software/systemd/man/logind.conf.html:
"If the system is inserted in a docking station, or if more than one display is connected, the action specified by HandleLidSwitchDocked= occurs; otherwise the HandleLidSwitch= action occurs."

In my case I don't have a docking station nor any other monitor attached to the laptop, so as Pranav suggested, there may be some issues with detecting the laptop as being docked or as having other connected monitors?

My machine has an Optimus card, with both Intel and Nvidia chips, could this be related to the bug? Any of you have machines with this system too?

Revision history for this message
Bruno Santos (bsantos) wrote :

patrick70 did you reboot or restart the systemd-logind service?

Revision history for this message
Carl (carl-leach-public-b) wrote :

VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)

Revision history for this message
Carl (carl-leach-public-b) wrote :

~$ xrandr --query
Screen 0: minimum 8 x 8, current 1366 x 768, maximum 32767 x 32767
LVDS1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1366x768 59.64*+
   1360x768 59.80 59.96
   1280x720 60.00
   1024x768 60.00
   1024x576 60.00
   960x540 60.00
   800x600 60.32 56.25
   864x486 60.00
   640x480 59.94
   720x405 60.00
   680x384 60.00
   640x360 60.00
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Revision history for this message
Julien Olivier (julo) wrote :

I, too, have an Optimus Prime video card (Nvidia GeForce 830M/PCIe/SSE2).

Revision history for this message
patrick70 (patrick70) wrote :

@Bruno
I rebooted the system.

Revision history for this message
patrick70 (patrick70) wrote :

It seems that there are two issues:
1) Wrong detection oft closed lid
Can be worked around with the aforementioned settings.

2) Failure to suspend at all
Incorrect state, fan still operating.
Failure to wake up in any event.

I wonder if I shall file a different bug for 2.

Revision history for this message
Carl (carl-leach-public-b) wrote :

I don't think it is 'Wrong detection of closed lid' as '/proc/acpi/button/lid/LID0/state' reports the open and close state correctly.

Revision history for this message
Wayne Brown (fwbrown) wrote :

My HP Pavilion 15 Notebook PC (15f019dx) had the same problem after upgrading to 16.04. It would suspend from the menu with no problem, but would not suspend automatically when the lid was closed. /proc/acpi/button/lid/LID0/state was reporting the lid closed as it should. Adding HandleLidSwitchDocked=suspend to /etc/systemd/logind.conf and then rebooting fixed it.

Revision history for this message
patrick70 (patrick70) wrote :

I found a solution to the issue '2) Failure to suspend at all': I upgraded the kernel to 4.4.8.

Now patching HandleLidSwitchDocked=suspend in /etc/systemd/logind works for me too.

Revision history for this message
Martin Pitt (pitti) wrote :

@patrick70: As you already found out, failures in the actual suspend are hardware/kernel specific. Great to hear that the new kernel works.

As for not suspending in the default configuration (i. e. without HandleLidSwitchDocked=suspend):

 - Does suspend work from the session indicator (rightmost in the top panel)?
 - Can you please copy&paste the output of "systemd-inhibit" in a situation where closing the lid does not do anything?
 - After a lid close/open without suspend, please do "sudo journalctl -b > /tmp/journal.txt" and attach /tmp/journal.txt here.

Changed in systemd (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
patrick70 (patrick70) wrote :

Suspend from the session indicator works.

systemd-inhibit:
     Who: patrick (UID 1000/patrick, PID 1564/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: Unity (UID 1000/patrick, PID 1570/compiz)
    What: sleep
     Why: Unity needs to lock the screen
    Mode: delay

     Who: patrick (UID 1000/patrick, PID 1564/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: NetworkManager (UID 0/root, PID 722/NetworkManager)
    What: sleep
     Why: NetworkManager muss Netzwerke abschalten
    Mode: delay

4 inhibitors listed.

Revision history for this message
Bruno Santos (bsantos) wrote :

I removed the workaround in logind.conf and as expected suspend stopped working. It does work from panel menu.

$ systemd-inhibit
     Who: Telepathy (UID 1000/bruno, PID 2482/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay

     Who: bruno (UID 1000/bruno, PID 2070/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: bruno (UID 1000/bruno, PID 2070/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: NetworkManager (UID 0/root, PID 904/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

4 inhibitors listed.

Revision history for this message
Richard Brooksby (rptb1) wrote :

rb@bluejay:~/git/mps/code$ systemd-inhibit
     Who: NetworkManager (UID 0/root, PID 812/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: rb (UID 1000/rb, PID 1589/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: rb (UID 1000/rb, PID 1589/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: Unity (UID 1000/rb, PID 1594/compiz)
    What: sleep
     Why: Unity needs to lock the screen
    Mode: delay

4 inhibitors listed.

Note: Closing the lid does switch off the display, but doesn't suspend the machine.

Here is the tail of the output of journalctl at the time I closed and opened the lid.

Apr 26 23:21:13 bluejay kernel: atkbd serio0: Unknown key pressed (translated set 2, code 0xd8 on isa0060/serio0).
Apr 26 23:21:13 bluejay kernel: atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known.
Apr 26 23:21:13 bluejay kernel: atkbd serio0: Unknown key released (translated set 2, code 0xd8 on isa0060/serio0).
Apr 26 23:21:13 bluejay kernel: atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known.
Apr 26 23:21:14 bluejay systemd-logind[828]: Lid closed.
Apr 26 23:21:17 bluejay systemd-logind[828]: Lid opened.
Apr 26 23:21:22 bluejay sudo[8534]: rb : TTY=pts/6 ; PWD=/home/rb/git/mps/code ; USER=root ; COMMAND=/bin/journalctl -b
Apr 26 23:21:22 bluejay sudo[8534]: pam_unix(sudo:session): session opened for user root by (uid=0)

Revision history for this message
Neil Woolford (neil-neilwoolford) wrote :

On my HP255G1 I have six inhibitors listed, the two blocks being;

     Who: neilw (UID 1000/neilw, PID 1669/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: neilw (UID 1000/neilw, PID 1669/unity-settings-)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

However, I certainly don't have multiple displays attached.

Revision history for this message
Martin Pitt (pitti) wrote :

@Neil: So for you, unity-settings-daemon mis-detects the displays and sets that inhibitor. This is a bug in unity-settings-daemon and thus a completely different root cause than the original one that patrick70 filed. Please file a separate bug about that, and include the output of "xrandr" there (or, if you have a bug marked as a duplicate, un-duplicate it).

Revision history for this message
Benoît Vézina (a-1enoit-n) wrote :

Same here dv7, closing lid, nothing happen

Revision history for this message
Neil Woolford (neil-neilwoolford) wrote :

The problem persists after sorting the oddity with the unity-settings-daemon, which appears to have been a one-off problem. (See bug #1577906 for more detail.)

Now I find that suspend only works if "HandleLidSwitchDocked=suspend" is in logind.conf.

Without that I return to the bug condition.

In the bug condition suspend works fine from the session indicator.

neilw@NWPS-LAP:~$ systemd-inhibit
     Who: neilw (UID 1000/neilw, PID 1558/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: NetworkManager (UID 0/root, PID 2267/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: Telepathy (UID 1000/neilw, PID 1797/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay

     Who: neilw (UID 1000/neilw, PID 1558/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: Unity (UID 1000/neilw, PID 1566/compiz)
    What: sleep
     Why: Unity needs to lock the screen
    Mode: delay

5 inhibitors listed.

Revision history for this message
Sam Brookfield (sbrookfield) wrote :

Affects HP Spectre z360 also (suspend works from interface but does not happen when lid closed despite setting in power settings) - had to both upgrade to kernel 4.4.8 from 4.4.0 and add the workarounds to /etc/systemd/login.d to get it to work - just upgrade / workaround did not work separately. No multiple displays or dock (xrandr confirmed) - but haven't checked if power connecter removed works without workaround (not any use to me).

systemd-inhibit output -
     Who: sam (UID 1000/sam, PID 1750/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: sam (UID 1000/sam, PID 1750/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: NetworkManager (UID 0/root, PID 873/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: sam (UID 1000/sam, PID 1757/gnome-session-b)
    What: shutdown:sleep
     Why: user session inhibited
    Mode: block

4 inhibitors listed.

Revision history for this message
Игорь (ifree92) wrote :

Have the same problem on HP Probook 450 G3
When lid was closed.. laptop didn't suspend. When I open lid.. I cannot click on some tray icon on top panel.

Revision history for this message
Игорь (ifree92) wrote :

On all previously versions all works fine.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@Sam,

your log states that gnome-session inhibits suspends, it's usually because some code asked it to do so

what if you try to

$ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager.GetInhibitors

then

$ dbus-send --print-reply --dest=org.gnome.SessionManager <object path> org.gnome.SessionManager.Inhibitor.GetAppId

where "object path" is the string returned by the previous call (e.g "/org/gnome/SessionManager/Inhibitor<n>")

Revision history for this message
Carl (carl-leach-public-b) wrote :

~$ systemd-inhibit
     Who: NetworkManager (UID 0/root, PID 686/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: Telepathy (UID 1000/carl, PID 1923/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay

     Who: carl (UID 1000/carl, PID 1805/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: carl (UID 1000/carl, PID 1805/gnome-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

4 inhibitors listed.

Revision history for this message
Игорь (ifree92) wrote :

Also in additions I propose this error from `dmesg` (for my HP Probook 450 G3) when I trying to close lid:

[ 2736.262341] atkbd serio0: Unknown key pressed (translated set 2, code 0x85 on isa0060/serio0).
[ 2736.262355] atkbd serio0: Use 'setkeycodes e005 <keycode>' to make it known.

May be it should help to resolve this error

Revision history for this message
Zed (darkbroodzed) wrote :

notebook hp x360 13-4002dx
new install 16.04
same issue "Notebook doesn't suspend when lid is closed"
adding HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf fix issue.

If need more info for making proper fix - ask

Revision history for this message
Sebastien Bacher (seb128) wrote :

Those who state that "HandleLidSwitchDocked=suspend" fixes their issue, could you undo that change and provide the "systemd-inhibit" "xrandr" and "loginctl" commands output?

Revision history for this message
Neil Woolford (neil-neilwoolford) wrote :

Ok.

Commented out the HandleLidSwitchDocked=suspend line and restarted systemd-logind.

Closed lid, waited a minute, the bug showed itself, the system did not suspend.

neilw@NWPS-LAP:/etc/systemd$ systemd-inhibit
     Who: Unity (UID 1000/neilw, PID 1463/compiz)
    What: sleep
     Why: Unity needs to lock the screen
    Mode: delay

     Who: neilw (UID 1000/neilw, PID 1448/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: neilw (UID 1000/neilw, PID 1448/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: Telepathy (UID 1000/neilw, PID 1729/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay

     Who: NetworkManager (UID 0/root, PID 2218/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

5 inhibitors listed.

neilw@NWPS-LAP:/etc/systemd$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1366x768 60.07*+ 40.04
   1280x720 59.86
   1152x768 59.78
   1024x768 59.92
   800x600 59.86
   848x480 59.66
   720x480 59.71
   640x480 59.38
HDMI-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)

neilw@NWPS-LAP:/etc/systemd$ loginctl
   SESSION UID USER SEAT
        c2 1000 neilw seat0

1 sessions listed.

Revision history for this message
Neil Woolford (neil-neilwoolford) wrote :

I've reinstated the workaround and run the requested commands again.

As far as I can see, the output of all three is exactly the same as in the bug condition, apart from the items in the inhibitors list being shown in a different order.

Revision history for this message
Sebastien Bacher (seb128) wrote :

hum, could you get in the buggy state, run a "sleep 10; systemd-inhibit", close the lid, wait until the 10s are over, open it back and see what that listed? it could be that one of the processes delaying suspend is

Changed in systemd (Ubuntu):
status: Incomplete → New
Changed in systemd (Ubuntu):
status: New → Confirmed
55 comments hidden view all 135 comments
Revision history for this message
Dan Palmer-Bancel (dan-palmer-bancel) wrote :

Apologies, I misread the above fix (it's been a long day!) :-/

HandleLidSwitchDocked=suspend

fixes the issue on 16.10 as well on my HP (not XP!) Spectre x360.

Fans came on for a minute or two after resume but have since stopped.

Revision history for this message
Ryan C. Underwood (nemesis-icequake) wrote :

Still happens on 16.10 on a HP Pavilion 15 (Skylake i5-6300HQ, Intel 530, Nvidia 950M).

HandleLidSwitchDocked=suspend and then reboot 'fixes' it.

However, it has the undesirable side effect of suspending when an external monitor is attached to the HDMI port (driven by the NVidia chip).

In the latter case, the system also fails to resume from suspend, leaving only a black screen. I'd be willing to believe that this particular case is due to bugs in the nouveau driver. But the system should not be suspending when there is an external display attached in any case - this appears to be systemd policy overriding GNOME policy.

Revision history for this message
Catch (catch22tb) wrote :

This occured to me today, seemingly after no update for changes made to my laptop. I fixed in in the following way. Hope this helps someone...

What did not work: Running the latest update, installing kernel 4.8.x or 4.4.25, or any of the fixes you can find doing a google search for kubuntu 16.04 suspend. I had finally tried a commond line common pm-suspend, which caused the laptop to freeze and then freeze on booting.

I have dell vostro 3500 laptop.

What worked: I reinstalled the kubuntu 16.04.1 base. I have a separate /home partition so that was not effected by the reinstall (i didn't format it. just specified to mount /home in the install setup).

reinstall was fast. After install finished, I also ran the update... to kernel 4.4.0-62-generic. I did not test the suspend here. I installed powernap and cpufreq, then rebooted. Later I closed the lid and the computer suspended. All set and it works fine.

Not sure what was the exact problem was or the fix.

Revision history for this message
Catch (catch22tb) wrote :

More on this, adding to my comment above... My computer ceases its ability to suspend again, without any updated etc. There was a notice that a program had crashed yesterday evening, but the computer suspended fine. This morning I noticed there was no sound (the speaker icon was red in kubuntu 16.04 task bar) and kwin-x11 was at 100% cpu. rebooting did not fix this.

I reinstalled pulseaudio, and cpufreqd cpufreuutil and rebooted. All fixed agin with sounds and suspend.

Revision history for this message
Damian Serrano Thode (dsthode) wrote :

HP Pavilion g6 here.

After upgrading the past month from 14.04 to 16.04, I was also affected by this bug, where with 14.04 I closed the lid and my laptop suspended as it should.

I tried to set HandleLidSwitch=suspend in logind.conf but it made no change, the laptop wouldn't suspend.

Today I upgraded from 16.04 to 16.10 and it was all the same, closing the lid of my laptop does not suspend it.

Reading the comments on this thread, I added HandleLidSwitchDocked=suspend to my logind.conf and now it works perfectly.

Revision history for this message
jgm (jogama) wrote :

Lenovo T450s with Intel graphics suffering from this bug. Suspend does indeed work from my session indicator, however.

Updated kernel from 4.4 to 4.8, nothing happened. Uncommented HandleLidSwitchDocked and set it to suspend. Still broken.

 - Can you please copy&paste the output of "systemd-inhibit" in a situation where closing the lid does not do anything?
 - After a lid close/open without suspend, please do "sudo journalctl -b > /tmp/journal.txt" and attach /tmp/journal.txt here.

Revision history for this message
jgm (jogama) wrote :

Please help? The usual fixes haven't worked for me.

Lenovo T450s with Intel graphics suffering from this bug. Suspend does indeed work from my session indicator, however.

Updated kernel from 4.4 to 4.8, nothing happened. Uncommented HandleLidSwitchDocked and set it to suspend. Still broken.

$ systemd-inhibit
     Who: Unity (UID 1000/jogama, PID 3944/compiz)
    What: sleep
     Why: Unity needs to lock the screen
    Mode: delay

     Who: NetworkManager (UID 0/root, PID 1103/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: jogama (UID 1000/jogama, PID 3680/unity-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: jogama (UID 1000/jogama, PID 3680/unity-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

4 inhibitors listed.

Revision history for this message
Carlo (carlo-b) wrote :

Just FYI I posted this https://lkml.org/lkml/2017/4/9/57 yesterday. Still to be reviewed.
Hope it helps.

Revision history for this message
Alf HP Lund (alf-c) wrote :

Ubuntu Studio 16.04 on Toshiba Satellite p850

Regardless of settings in power manager or logind.conf, machine will not suspend on lid close. It will turn off the screen, though.

Suspend from menu, command or power button works.

Lid state is reported correct (cat /proc/acpi/button/lid/LID0/state)

However, as described here: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/1037860 lid close will suspend if I remove the power cable. As checked with acpi_listen, lid close alone does not generate any ACPI event.

Revision history for this message
Menahem Julien Raccah Lisei (menajrl) wrote :

Neither HandleLidSwitch, nor HandleLidSwitchDocked explicitly un-commented and set as "suspend" worked for me on Ubuntu 17.04.

The machine neither suspends on lid down, nor does it prompt me for a password on lid up.

Revision history for this message
Bob (caltinay) wrote :

I have the same issue on a HP ZBook G3 running Debian with the 4.11 kernel from experimental and after reading comment #103 I tried
rmmod hp_wmi
and this fixed it!

So hopefully an updated kernel will fix it properly with that driver loaded.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I think there are two ongoing patches are going to address this, maybe worth a try:

One is from Benjamin Tissoires:
https://patchwork.kernel.org/patch/9760869/

Another one is from Lv Zheng:
https://patchwork.kernel.org/patch/9771121/

Revision history for this message
zaharmd (zaharmd) wrote :

HP EliteBook 840 G3, Xubuntu 17.04
Workaround by - rmmod hp_wmi

Revision history for this message
Benjamin Halbrock (kontakt-bennis-blog) wrote :

HP ProBook 440 G4, fix in #108 works for me, but I'm not sure what the purpose of this module is and if it is save to blacklist.

dmesg also has some strange keycode on closing and opening the lid (see #38)

[ 750.004558] atkbd serio0: Unknown key pressed (translated set 2, code 0x85 on isa0060/serio0).
[ 750.004569] atkbd serio0: Use 'setkeycodes e005 <keycode>' to make it known.

Revision history for this message
Benjamin Halbrock (kontakt-bennis-blog) wrote :

quick update to #109

adding HandleLidSwitchDocked=suspend to

/etc/systemd/logind.conf

is also working

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please try latest mainline kernel - Carlo's patches are included.

Revision history for this message
Bob (caltinay) wrote :

Updated to 4.12.2 (from Debian experimental) and the issue is resolved on my HP ZBook G3.

Revision history for this message
Ilja Polivanovas (ilja-polivanovas) wrote :

Using 17.04 Gnome,
Kernel 4.10.0-28-generic

Problem is still here on Dell XPS 13 (9350).

Neither of this has no effect:
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

PC still runnning after lid is closed. However lid state is reported correctly.

$ sleep 5; cat /proc/acpi/button/lid/LID0/state
state: closed

Revision history for this message
Ilja Polivanovas (ilja-polivanovas) wrote :

Ok Sorry for misleading report on #113.
It actually works, however the problem was with Tweak tool setting which silently adds autostart script preventing notebook to suspend on lid closed regardless settings in /etc/systemd/logind.conf
More: https://unix.stackexchange.com/questions/307497/gnome-disable-sleep-on-lid-close

Revision history for this message
Bill Duetschler (bikergeek) wrote :

HP 450 G3 laptop here, just a few days old. Adding the "HandleLidSwitchDocked=suspend" worked for me. Ubuntu Zesty, kernel 4.10.0-32.

Revision history for this message
Bill Duetschler (bikergeek) wrote :

Looks like I misspoke, adding "HandleLidSwitchDocked=suspend" didn't work. I took the laptop offsite after closing the lid and when I arrived at my destination the laptop was still warm and there had been significant battery drain, as if it had been running full-blast all along.

Revision history for this message
Bill Duetschler (bikergeek) wrote :

Installing the "pm-utils" package--which for some reason wasn't installed on a fresh install of Ubuntu 17.04--fixed it, along with altering my /etc/systemd/logind.conf did the trick. I altered it to read:

HandleSuspendKey=suspend
HandleHibernateKey=suspend
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

And now everything works.

Revision history for this message
Carlos Gomes (gocarlos) wrote :

My Thinkpad P51 is also affected by this bug.
Gnome tweak tools is set to suspend on lid close, but nothing happens.

Revision history for this message
Carlos Gomes (gocarlos) wrote :

Most important information: I'm using ubuntu 18.04, fresh install

Revision history for this message
Anders Ellenshøj Andersen (andersa-ellenshoej) wrote :

Kubuntu 18.04 on Zenbook Pro UX550VE. Also doesn't work. Tried all the suggestions like installing pm-utils and modifying logind.conf. Nothing has helped.

Revision history for this message
Josh Hill (ingenium) wrote :

I'm experiencing this issue after upgrading from 16.04 to 18.04 on a Thinkpad T460p.

I have set the following in /etc/systemd/logind.conf and restarted systemd-logind.service (which logged me out of my session)

HandleSuspendKey=suspend
HandleHibernateKey=suspend
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

journalctl shows "systemd-logind[20403]: Lid closed." when I close the lid, but it does not take any action other than my external monitor shutting off briefly before turning back on. pm-utils is installed. There's nothing else in the system logs related to suspend, and the power light on the laptop lid does not start pulsing like it used to do when it began to suspend. So the lid closed event is not triggering it to attempt to suspend, despite the correct logind configuration.

My laptop is in a docking station and also has an external monitor connected.

Revision history for this message
Josh Hill (ingenium) wrote :

One other note, it appears that gsd-power might be blocking the suspend:

josh@josh-ThinkPad-T460 ~ systemd-inhibit
     Who: gdm (UID 147/gdm, PID 3040/gsd-power)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: NetworkManager (UID 0/root, PID 1524/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: josh (UID 1000/josh, PID 20754/gsd-power)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: gdm (UID 147/gdm, PID 3037/gsd-media-keys)
    What: sleep
     Why: GNOME handling keypresses
    Mode: delay

     Who: Telepathy (UID 1000/josh, PID 4930/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay

     Who: josh (UID 1000/josh, PID 20754/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

     Who: gdm (UID 147/gdm, PID 3040/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

     Who: gdm (UID 147/gdm, PID 3037/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: josh (UID 1000/josh, PID 20741/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: UPower (UID 0/root, PID 2813/upowerd)
    What: sleep
     Why: Pause device polling
    Mode: delay

     Who: ModemManager (UID 0/root, PID 1466/ModemManager)
    What: sleep
     Why: ModemManager needs to reset devices
    Mode: delay

     Who: josh (UID 1000/josh, PID 20741/gsd-media-keys)
    What: sleep
     Why: GNOME handling keypresses
    Mode: delay

     Who: GNOME Shell (UID 1000/josh, PID 20651/gnome-shell)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

13 inhibitors listed.

And this related bug https://github.com/systemd/systemd/issues/7137

In the gnome power settings, on 16.04 there was a toggle to have it perform suspend with the lid closed while docked or while an external monitor was connected. That option is now gone.

Revision history for this message
Cornelius (7-cornelius) wrote :

Same on dell precision with nvidia Quadro M1000M:

# systemd-inhibit --list --mode=block
     Who: gdm (UID 128/gdm, PID 5533/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: dirmeier (UID 1001/dirmeier, PID 6669/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: gdm (UID 128/gdm, PID 5548/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

     Who: dirmeier (UID 1001/dirmeier, PID 6605/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

4 inhibitors listed.

But I have only my laptop open without any monitor attached.

So maybe it is not a bug in systemd?

Revision history for this message
mike-g2 (mikeg-utk) wrote :

I have had this problem in the past and it reemerged on an upgrade from 16.04 to 18.04 and have resolved it. For me (Lenovo Yoga) the issue is with USB rewaking the machine.

The following fix worked for me.

1) Created file: /etc/systemd/system/toggle.XHC.to.fix.suspend.issue.service
with following informaiton

[Unit]
Description="Make suspend ignore USB wake up."

[Service]
ExecStart=/bin/bash -c "echo XHC >> /proc/acpi/wakeup"

[Install]
WantedBy=multi-user.target

2) Created a symbolic link to above script in /etc/systemd/system/multi-user.target.wants

3) Executed following commands
                sudo systemctl daemon-reload
                                                                                             sudo systemctl start toggle.XHC.to.fix.suspend.issue.service

4) checked service was started with sudo systemctl status toggle.XHC.to.fix.suspend.issue.service 5) Enable it on boot with
                sudo systemctl enable toggle.XHC.to.fix.suspend.issue.service
Notes:

Revision history for this message
mike-g2 (mikeg-utk) wrote :

I have had this problem in the past and it reemerged on an upgrade from 16.04 to 18.04 and have resolved it. For me (Lenovo Yoga) the issue is with USB rewaking the machine.

The following fix worked for me.

1) Created file: /etc/systemd/system/toggle.XHC.to.fix.suspend.issue.service
with following informaiton

[Unit]
Description="Make suspend ignore USB wake up."

[Service]
ExecStart=/bin/bash -c "echo XHC >> /proc/acpi/wakeup"

[Install]
WantedBy=multi-user.target

2) Created a symbolic link to above script in /etc/systemd/system/multi-user.target.wants

3) Executed following commands
                sudo systemctl daemon-reload
                sudo systemctl start toggle.XHC.to.fix.suspend.issue.service

4) checked service was started with
      sudo systemctl status toggle.XHC.to.fix.suspend.issue.service

5) Enable it on boot with
             sudo systemctl enable toggle.XHC.to.fix.suspend.issue.service

Last steps are based on
https://www.reddit.com/r/archlinux/comments/3zxg65/how_to_permanently_change_procacpiwakeup_or/

Revision history for this message
Shri (shriharikulkarni07) wrote :

Happens with me too

Revision history for this message
Gaute (gaute-div) wrote :

I have a similar problem on 18.04 on a Lenovo V330.
Suspend works fine without external monitor, but no matter what I do it's inhibited when its connected. I want it to suspend always.

$ grep -i lid /etc/systemd/logind.conf
#HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend
#LidSwitchIgnoreInhibited=yes

$ dconf read /org/gnome/settings-daemon/plugins/power/lid-close-suspend-with-external-monitor
true

$ systemd-inhibit --list --mode=block
<snip>
     Who: gdm (UID 121/gdm, PID 5935/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

     Who: gaute (UID 1000/gaute, PID 1713/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

Only the second of these goes away when monitor is unplugged, but lid close still works.

This is possibly due to a bug in gsd-power which is mentioned in the following guthub issues.
https://github.com/systemd/systemd/issues/7137
https://github.com/linuxmint/cinnamon-settings-daemon/issues/224
https://github.com/linuxmint/Cinnamon/issues/7347

Revision history for this message
Jaime Hablutzel (hablutzel1-h) wrote :

I'm experiencing the same that Gaute in Ubuntu 18.04.2 LTS: Suspending on closing the lid is only working without the external monitor connected, no matter what I try to configure.

tags: added: eoan
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in pm-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
naisanza (naisanza) wrote :

Same problem with Ubuntu 19.04 on Dell XPS 13 2-in-1 (2019)

Revision history for this message
Full Name (unusedusername) wrote :

Same problem on Ubuntu 19.10 on HP 250 G7.

Tried editing logind.conf as per previous suggestions, but no combination solved the problem.

Tried installing pm-utils, which weren't installed (see #117), that didn't help either.

Tried turning off the automatic suspend and automatic blank screen in the Power settings, thinking that they might for whatever reason be interfering; no success.

Tried uncommenting InhibitDelayMaxSec, HoldoffTimeoutSec and LidSwitchIgnoreInhibited (with both 'yes' and 'no'), none of those did it.

Closing the lid only blanks the screen (fans are running), even if I leave it for some time. Opening the lid turns the screen back on, but doesn't open up the login screen.

Besides the unsuccessful editing of logind.conf, the only other concurrent issue that I haven't found anyone else encountering, is that, in my case, closing the lid and then opening it also turns on Airplane mode, and then the next time I close it and open it, it turns the Airplane mode off.

As I often need a quick suspend, as a temporary workaround, I set it up so that the physical power button suspends it. This works as intended, without any problems, so instead of having to close the lid, I have to press the button, then close the lid. It's better than having to open the top right menu, press Alt and click suspend, then close the lid, every time, but I'd still like to solve the problem properly...

Revision history for this message
Bob (caltinay) wrote :

@unusedusername I found a snippet somewhere that helped me do things when my lid is closed (or rather when the session is locked). Since your laptop switches to airplane mode something is detecting it so maybe this helps. Put this in a script and run it, then close lid and open lid. Do you get any output?

<snip>
#!/bin/sh
iface=org.freedesktop.login1.Session
dbus-monitor --system --profile "type=signal,interface=$iface" 2>/dev/null |
 while read type stamp sender dest path intf member; do
  case "$member" in
    *Lock)
        date
        echo LOCKED at $stamp ;;
    *Unlock)
        date
        echo UNLOCKED at $stamp ;;
    *)
  esac
done

</snip>

If it works you could even insert a suspend command and run this in the background to avoid having to use the mouse.

Revision history for this message
MohammadAli (aliomidi) wrote :

Same problem with Ubuntu 20.04.1 LTS on Asus N55sf laptop.

Revision history for this message
thinkpad (fellowsgarden) wrote :

bump. thinkpad x1 5th gen carbon.

Dan Streetman (ddstreet)
Changed in systemd (Ubuntu):
status: Confirmed → Invalid
status: Invalid → Won't Fix
status: Won't Fix → Incomplete
Revision history for this message
Nick Rosbrook (enr0n) wrote :

This bug is stale, so marking Won't Fix for systemd. For any similar issues on newer releases/hardware, new bugs should be opened.

Changed in systemd (Ubuntu):
status: Incomplete → Won't Fix
Displaying first 40 and last 40 comments. View all 135 comments or add a comment.