[SOLVED] Laptop not suspending on lid close

gsingh93 · 2015-11-22 08:57:09

My laptop used suspend on lid close, but it's not anymore after an upgrade. I've tried rebooting it. `/etc/systemd/logind.conf` is the default config, and evtest shows closing the lid is generating signals, as you can see below:

$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	AT Translated Set 2 keyboard
/dev/input/event1:	Lid Switch
/dev/input/event2:	Power Button
/dev/input/event3:	Power Button
/dev/input/event4:	HP Wireless hotkeys
/dev/input/event5:	ST LIS3LV02DL Accelerometer
/dev/input/event6:	HP WMI hotkeys
/dev/input/event7:	Video Bus
/dev/input/event8:	SynPS/2 Synaptics TouchPad
/dev/input/event9:	HDA Intel HDMI HDMI/DP,pcm=3
/dev/input/event10:	HDA Digital PCBeep
/dev/input/event11:	HDA Intel PCH Mic
/dev/input/event12:	HDA Intel PCH Headphone
/dev/input/event13:	HP Truevision HD
Select the device event number [0-13]: 1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0
Input device name: "Lid Switch"
Supported events:
  Event type 0 (EV_SYN)
  Event type 5 (EV_SW)
    Event code 0 (SW_LID) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1448182298.508649, type 5 (EV_SW), code 0 (SW_LID), value 1
Event: time 1448182298.508649, -------------- SYN_REPORT ------------
Event: time 1448182301.112605, type 5 (EV_SW), code 0 (SW_LID), value 0
Event: time 1448182301.112605, -------------- SYN_REPORT ------------

Any ideas what's wrong?

Last edited by gsingh93 (2015-12-13 02:13:59)

ewaller · 2015-11-22 17:34:42

There are several things that will take ownership of this. Generally, systemd handles it based on the file you linked. KDE and Gnome can override this and so can acpid. Are you using any of these?
I thought I had disabled this on my system because I do not want this behavior. I also use the closing of the lid to disable my touchpad through acpid.

Try this. Do a journalctl -f This command displays the last few lines of the journal, then waits for new journal entries which are then printed as they arrive. Close the lid, and open it. Do you see the systemd-login messages?

Nov 22 09:25:25 turing systemd-logind[455]: Lid closed.
Nov 22 09:25:25 turing root[18853]: LID closed, touchpad off
Nov 22 09:25:25 turing root[18856]: ACPI group/action undefined: button/wlan / WLAN
Nov 22 09:25:30 turing systemd-logind[455]: Lid opened.
Nov 22 09:25:30 turing root[18858]: LID opened, touchpad on

I am thinking the defaults might have changed.

Head_on_a_Stick · 2015-11-22 20:22:54

Please post the output of:

systemd-inhibit

Last edited by Head_on_a_Stick (2015-11-22 20:23:24)

gsingh93 · 2015-11-22 20:32:11

I'm not using GNOME or KDE, I'm using i3. I can see the system-logind messages in journalctl.

Here's the output of `systemd-inhibit`:

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

1 inhibitors listed.

gsingh93 · 2015-11-24 02:20:03

Does this mean NetworkManager is causing the issue or is it related to something else?

myk1985 · 2015-11-24 18:08:21

gsingh93 wrote:

Does this mean NetworkManager is causing the issue or is it related to something else?

No. This means every time the system is going to sleep NetworkManager needs a little time to turn off networks. When NetworkManager is done (or out of time) the system still is going to sleep.
(A side note: As far as I understand, systemd-logind's documentation uses the word "sleep" to describe suspend or hibernate in a generic way. So a system going to sleep may actually be suspending or starting to hibernate).
This is indicated by the Why field's value (obviously) and the Mode field's value which is "delay" in this case.

If an application or user was trying to completely prevent systemd-logind from reacting to an event the Mode field's value would be "block"
(You can take a look here for details -- http://www.freedesktop.org/wiki/Softwar … d/inhibit/)

Maybe try editing your logind.conf and explicitly set

HandleLidSwitch=suspend

(Please have a look here for documentation -- http://www.freedesktop.org/software/sys … .conf.html)

If you decide to try editing the logind.conf, don't forget to make systemd-logind reload it when finished editing

sudo systemctl restart systemd-logind

Instead of restarting the systemd-logind service you can reboot if you suspect it did not read the config changes.
But in my experience just restarting the service is enough to make it pick up the config's changes.

Hope this helps.

Last edited by myk1985 (2015-11-24 18:13:22)

gsingh93 · 2015-11-26 02:34:22

Tried it, but it didn't work. Any other ideas?

myk1985 · 2015-11-26 21:10:20

Hi gsingh93,

As ewaller suggested, open a terminal emulator in your window manager and execute

sudo journalctl --unit=systemd-logind --follow

Leave the terminal open.
Close the lid. Wait a little -- give it 30 seconds or a minute. Open the lid.

Please post the output of the journalctl command. Hopefully, it will contain a clue about what's going on.

gsingh93 · 2015-11-27 05:10:15

Looks like pretty standard stuff to me:

Nov 25 20:04:44 arch systemd-logind[19590]: Lid opened.
Nov 25 20:04:44 arch systemd-logind[19590]: Operation finished.
Nov 26 10:56:21 arch systemd-logind[19590]: Operation finished.
Nov 26 21:03:32 arch systemd-logind[19590]: Operation finished.
Nov 26 21:08:52 arch systemd-logind[19590]: Lid closed.
Nov 26 21:08:57 arch systemd-logind[19590]: Lid opened.

myk1985 · 2015-11-27 20:49:14

Yep, nothing special.

Well, one more thing to try is to reboot and pass

systemd.log_level=debug

on the kernel's command line.

The system will generate a lot of messages while booting with this...
Once the system is booted repeat the steps with journalctl (you may need to use the "--priority=debug" param with journalctl -- http://www.freedesktop.org/software/sys … lctl.html).
It should give much more details in the log this time.

In particular, maybe there'll be the reason why logind doesn't suspend your laptop when the lid is closed.

It does "see" the lid events, it is configured to suspend on the lid closing, so there should be something it doesn't "like" and will complain about.

gsingh93 · 2015-11-29 23:48:14

Here is the new output:

Nov 29 15:46:58 arch systemd-logind[573]: Lid closed.
Nov 29 15:46:58 arch systemd-logind[573]: System is docked.
Nov 29 15:46:58 arch systemd-logind[573]: Refusing operation, as it is turned off.
Nov 29 15:46:58 arch systemd-logind[573]: System is docked.
Nov 29 15:46:58 arch systemd-logind[573]: Refusing operation, as it is turned off.
Nov 29 15:46:58 arch systemd[1]: systemd-logind.service: Got notification message from PID 573 (WATCHDOG=1)
Nov 29 15:47:07 arch systemd-logind[573]: Lid opened.

Does "docked" here mean the power cable is plugged in? Because it's not...

myk1985 · 2015-12-05 00:39:45

Does "docked" here mean the power cable is plugged in? Because it's not...

"Docked" means systemd-logind thinks your laptop is attached to a dock station (https://en.wikipedia.org/wiki/Docking_station)

I have never owned a docking station so unfortunately I don't know how the systems detects whether a laptop is docked or not.
I guess, it could be a "button" which is depressed when the laptop is attached to a dock. Or it may be an electrical detector circuit which is closed when the laptop is docked.
Anyway, what I'm getting at is see if anything is physically stuck or damaged in your laptop and maybe that something makes it think it is docked.

Meanwhile, there is the HandleLidSwitchDocked option in /etc/systemd/logind.conf.
It is the same as HandleLidSwitch but the logind service uses the former instead of the latter when the laptop is docked.
As far as I understand, your laptop is not actaully docked. But since the logind service thinks it is docked, the HandleLidSwitchDocked setting is being used.

Try uncommenting it and explicitely setting its value:

HandleLidSwitchDocked=suspend

Keep in mind to force logind to reread logind.conf.

Last edited by myk1985 (2015-12-05 00:40:19)

gsingh93 · 2015-12-13 02:14:40

Yup, `HandleLidSwitchDocked=suspend` fixed it. It's a hacky fix (I have no clue why my computer thinks it's docked), but it works. Thanks!

Arch Linux

#1 2015-11-22 08:57:09

[SOLVED] Laptop not suspending on lid close

#2 2015-11-22 17:34:42

Re: [SOLVED] Laptop not suspending on lid close

#3 2015-11-22 20:22:54

Re: [SOLVED] Laptop not suspending on lid close

#4 2015-11-22 20:32:11

Re: [SOLVED] Laptop not suspending on lid close

#5 2015-11-24 02:20:03

Re: [SOLVED] Laptop not suspending on lid close

#6 2015-11-24 18:08:21

Re: [SOLVED] Laptop not suspending on lid close

#7 2015-11-26 02:34:22

Re: [SOLVED] Laptop not suspending on lid close

#8 2015-11-26 21:10:20

Re: [SOLVED] Laptop not suspending on lid close

#9 2015-11-27 05:10:15

Re: [SOLVED] Laptop not suspending on lid close

#10 2015-11-27 20:49:14

Re: [SOLVED] Laptop not suspending on lid close

#11 2015-11-29 23:48:14

Re: [SOLVED] Laptop not suspending on lid close

#12 2015-12-05 00:39:45

Re: [SOLVED] Laptop not suspending on lid close

#13 2015-12-13 02:14:40

Re: [SOLVED] Laptop not suspending on lid close

Board footer