Suspend on lid close not working

[T3Q]

This might sound like it already has been answered a couple times, but to me this seems a bit different from the other forum post about lid closing behaviour.

Whats the problem: When I close the lid, it stays on.
What it should do: Enter sleep (in the logs its called suspend, I definitely do NOT mean hibernation)
I am running EOS 2025.03.19 with KDE Plasma 6.3.4

Stuff I already checked:

• logind.conf entries for HandleLidSwitch are set to suspend an uncommented (removed #)
• KDE powermanagement is set to sleep when laptop lid closed
• systemd-inhibit --list: returns Network manager, UPower, Screenlocker, and PowerDevil(“KDE handles power events”)
• journalctl -u systemd-logind → does not show that lid close / open is detected
• cat /proc/acpi/button/lid/LID/state is always “open”, even when the lid is closed.

Lid closing detection works on Windows 11 and Ubuntu 24.

I’d very much appreciate any help or pointer what to look into.

[SynAck]

Hi T3Q & welcome to the forum.

Just curious, does the system suspend correctly when you enter the following shell command?
systemctl suspend

[T3Q]

Hi SynAck
yes, suspending works otherwise, be it via CLI or the logout screen. But as soon as I close the lid, it presses upon some key and wakes up again.

[xircon]

I think there has been a kernel regression, was working here, stopped a few days ago.

[T3Q]

I am not sure if lid triggered sleep ever worked for me on EOS.

[SynAck]

I run EnOS + KDE Plasma on a Dell 7480 (kernel 6.12.24-1-lts), closing the lid correctly triggers suspend & it enters hibernate after the specified duration.

It was smart of you to check for lid events with journalctl -u systemd-logind | grep Lid, doing same on my Dell returns:

Mmm dd hh:mm:ss hostname systemd-logind[###]: Watching system buttons on /dev/input/event0 (Lid Switch)
Mmm dd hh:mm:ss hostname systemd-logind[###]: Lid closed.
Mmm dd hh:mm:ss hostname systemd-logind[###]: Lid opened.
...etc...

Perhaps that is where we should look for root cause, maybe the “Lid Switch” system button isn’t sending an event or it isn’t being watched?

I rebooted my Dell on kernel 6.14.3-arch-1 then tested lid close/open - it correctly suspended & resumed.

When I checked output from yay there are indeed kernel updates available (for my Dell):

core/linux               6.14.3-arch-1  -> 6.14.5-arch-1
core/linux-headers       6.14.3-arch-1  -> 6.14.5-arch-1
core/linux-lts           6.12.24-1      -> 6.12.27-1
core/linux-lts-headers   6.12.24-1      -> 6.12.27-1

Which kernel are you using, can you try booting LTS to see if the issue persists with it? If you need to install LTS don’t forget headers:
sudo pacman -S linux-lts linux-lts-headers

& update GRUB if you use that:
sudo grub-mkconfig -o /boot/grub/grub.cfg

or if using the default installed systemd-boot in the default configuration then IIRC the new boot entry should be automatically detected & managed, but here are 2 relevant links worth reading:

https://discovery.endeavouros.com/installation/systemd-boot/2022/12/

Systemd-boot and multiple kernels

The method that will survive the kernel being renamed is the one described in post 2: Systemd-boot and multiple kernels - #2 by BluishHumility I also found the wiki entry dalto mentioned, which bears the same explanation: https://discovery.endeavouros.com/installation/systemd-boot/2022/12/ How to change the default entry to boot There is a default entry inside /efi/loader/loader.conf that determine the default boot entry. On a new install, it will look something like this: default 665eca4ae…

[T3Q]

I am currently running 6.14.4-arch1-2.
I have no experience with changing the kernel, but Ill have a look into that when I find some time and made a backup of everything.

[SynAck]

I find it very useful to always keep lts/lts-headers installed as it provides a very handy fallback if recent kernel updates cause an issue, in which case you simply reboot & choose the lts kernel at boot time.

Or in my case: just default to lts & keep on truckin’

Let us know if you need any help with this, I’m sure many will chip in to help.
Happy hunting, & once again: welcome to EnOS , simply the best OS (IMHO).

[SynAck]

I just found a script someone wrote for testing this exact event; open your terminal & paste (Ctrl+Shift+Enter) the following in then hit Enter:

cat << 'EOF' > ~/Desktop/lid.sh
while true; do
    state=$(cat /proc/acpi/button/lid/LID0/state)
    if [ "$state" != "$old_state" ]; then
        echo -en "\a"
    fi
    echo $state
    old_state=$state
    sleep 1
done
EOF
chmod +x ~/Desktop/lid.sh && ~/Desktop/lid.sh

This will print changes in /proc/acpi/button/lid/LID0/state once per second & run until cancelled or the terminal is closed.

Now simply close the lid, wait a few seconds, & reopen it to check the output. The file can be deleted from your desktop when no longer needed.

[T3Q]

I already used while True; do cat /proc/acpi/button/lid/LID/state; sleep .1; done to check the lid state when it was closed. As I wrote in the beginning, it stays “open” even when the lid is closed.

[SynAck]

Leaving the script running while you’re testing might be helpful.

Also, you used the plural in “logind.conf entries for HandleLidSwitch are set to suspend”, I assume this includes HandleLidSwitchExternalPower & HandleLidSwitchDocked too. Interestingly, my Dell has both set to suspend & docked set to ignore but commented out with # as are all entries in its logind.conf (it uses systemd).

My output of systemd-inhibit --list for comparison:

WHO            UID  USER  PID  COMM            WHAT                                                                       WHY                                                        MODE 
NetworkManager 0    root  597  NetworkManager  sleep                                                                      NetworkManager needs to turn off networks                  delay
UPower         0    root  862  upowerd         sleep                                                                      Pause device polling                                       delay
PowerDevil     1000  unit 1059 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power events                                   block
Screen Locker  1000  unit 821  kwin_wayland    sleep                                                                      Ensuring that the screen gets locked before going to sleep delay

I did nothing special to setup lid=sleep on my Dell, just configured KDE Power Management thus:

• On AC Power = When laptop lid closed: sleep, When sleeping enter: Standby
• On Battery = When laptop lid closed: sleep, , When sleeping enter: Standby, then hibernate

I guess I could try installing the newer kernel to see if lid events break for me, but I would try booting lts first.