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

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

Happens on my HP ProBook 640 G2 too.

Same thing on a HP Sleekbook 15

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

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.

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

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

Same issue on HP G62-105SA Notebook PC.

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

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

Also affects my HP Stream 11.

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?

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

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

~$ 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)

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

@Bruno
I rebooted the system.

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.

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.

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.

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.

@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.

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.

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.

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)

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.

@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).

Same here dv7, closing lid, nothing happen

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.

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.

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.

On all previously versions all works fine.

@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>")

~$ 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.

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

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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/

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

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.

quick update to #109

adding HandleLidSwitchDocked=suspend to

/etc/systemd/logind.conf

is also working

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

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

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

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

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

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.

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.

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

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

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.

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.

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.

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?

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:

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/

Happens with me too

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

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.

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

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

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...

@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.

Same problem with Ubuntu 20.04.1 LTS on Asus N55sf laptop.

bump. thinkpad x1 5th gen carbon.

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