In order to fix some reliability issues with suspend-to-ram (upon laptop lid being closed), I want to inquire which software is involved with this. So that I can resolve the following issues:

  • "suspend-to-ram" working well depends on login state and tty3. I have both wayland and Xorg and sometimes a console running on 1 to 5 ttys
  • there seems to be systemd logind some of my DE's (most prominently Gnome3 and xfce) involved.
  • upon reopening the lid and the resume from the last suspend-to-ram the gdm thing does not allow a "suspend-to-ram", forcing me to lock in prior to having another chance (it is unreliable) of a "suspend-to-ram" which in itself takes up to 5+ seconds (which I can tell from having audio playing at that very moment, from lid-close to music off it is easily 7 to 10 seconds)

I remember (from previous dealing with similar matter relating to suspend-to-ram) that "modern" Linux with Gnome and systemd and loginkit, and logind was prone to issues with suspend, as different software is related to tell "lid closed" and yet "inhibit suspend-to-ram".

A good answer would at the very least list the software that is involved with suspend to ram. Better it would also briefly sketch the order and the role the different software is playing.

Provided that it might depend on the init and desktop environment I am most interested in answers related to

  • systemd
  • debian / ubuntu 18.04
  • Gnome 3

A best answer would also highlight how I can at best disable any software and GUI related thing enter image description here

and other "helpful" automatism as for me a mere basic (but working):

root@box$ while sleep 1; do 
    grep "closed" /proc/acpi/button/lid/LID0/state && {
        systemctl suspend 
        sleep 3 

would suffice.

Anyway the core info this question seeks to find out is (what software involves itself in the task to "check lid state" and consequently "suspend-to-ram"?)

  • Do you have any process called acpid or something like that running on your system ?
    – binarym
    Commented Nov 28, 2019 at 9:00
  • @binarym, yes /usr/sbin/acpid is running
    – fraleone
    Commented Nov 28, 2019 at 9:04

1 Answer 1


Ok, so since acpid looks to be running on your system (see comments), it's probably this software component which rules the power management.

It's configured through /etc/acpi/. For example, in my Debian, i have a /etc/acpi/events/lidbtn configuration file which is used to define how to react for every events related to the lid.

It contains:

# /etc/acpi/events/lidbtn
# Called when the user closes or opens the lid

event=button[ /]lid

Then, i want to add some actions to be run during lid close, i just have to add it on the right place of the /etc/acpi/lid.sh shell. There's a lot of environment variable set by acpid that can help detecting event type.

You can read the manpage of acpid for more details.

  • Being also the reason for my question in the first place, it seems that other software such as systemd-logind and its related configure file /etc/systemd/logind.conf have also two settings HandleLidSwitchDocked HandleLidSwitch. I am happy and grateful about your answer, but if possible I think it would be even better to tell more about the complete picture. Clearly more than one software package is involved with "lid close" and "suspend-to-ram" here. Where for instance does Gnome integrate, and how does gdm (considering suspend stops working at the gdm login screen)...
    – fraleone
    Commented Nov 28, 2019 at 9:45
  • I would have upvoted your answer but, this is not my usual account and I lack sufficient reputation ....
    – fraleone
    Commented Nov 28, 2019 at 9:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .