Configuring power and hardware related events
A month ago I revived my old-laptop-as-server I have at home. I don't do much in
it, just serve my photos, a map, provide a ssh
trampoline for me and some
friends and not much more. This time I decided to tackle one of the most
annoying problems I had with it: That closing the lid led to the system to
suspend.
Now, the setup in that computer has evolved through some years, so a lot of cruft was left on it. For instance, at some point I solved the problem by installing a desktop and telling it not to suspend the machine, mostly because that's how I configure my current laptop. That, of course, was a cannon-for-killing-flies solution, but it worked, so I could focus in other things. Also, a lot of power-related packages were installed, assuming the were really needed for supporting everything I might ever wanted to do about power. This is the story on how I removed them all, why, and how I solved the lid problem... twice.
First thing to go were the desktop packages, mostly because the screen in that laptop has been dead for more than a year now, and because its new space in the house is a small shelf in my wooden desktop. Then I reviewed the power-related packages one by one and decided whether I needed it or not. This is more or less what I found:
-
acpi-fakekey
: This package has a tool for injecting fake ACPI keystrokes in the input system. Not really needed. -
acpi-support
: It has a lot of scripts that can be run when some ACPI events occur. For instance, lid closing, battery/AC status, but also things like responding to power and even 'multimedia' keys. Nice, but not needed in my case; the lid is going to be closed all the time anyways. -
laptop-mode-tools
: Tools for saving power in your laptop. Not needed either, the server is going to be running all the time on AC (its battery also died some time ago). -
upower
: D-Bus interface for power events. No desktop or anything else to listen to them. Gone. -
pm-utils
: Nice CLI scripts for suspending/hibernating your system. I always have them around in my laptop because sometimes the desktops don't work properly. No use in my server, but it's cruft left from when I used it as my laptop. Adieu.
Even then, closing the lid led to the system suspending. Who else could be there?
Well, there is one project who's being everywhere: systemd
. I'm not saying
this is bad, but it is everywhere. Thing is, its login subsystem also handles
ACPI events. In the /etc/systemd/logind.conf
file you can read the following
lines:
#HandlePowerKey=poweroff #HandleSuspendKey=suspend #HandleHibernateKey=hibernate #HandleLidSwitch=suspend #HandleLidSwitchDocked=ignore
so I uncommented the 4th line and changed it so:
HandleLidSwitch=ignore
Here you can also configure how the inhibition of actions work:
#PowerKeyIgnoreInhibited=no #SuspendKeyIgnoreInhibited=no #HibernateKeyIgnoreInhibited=no #LidSwitchIgnoreInhibited=yes
Please check the config file's doc if you plan to modify it.
Not entirely unrelated, my main laptop also started suspending when I closed the lid. I have it configured, through the desktop environment, to only turn off the screen, because what use is the screen if it's facing the keyboard and touchpad :) Somehow, these settings only recently started to be in effect, but a quick search didn't gave any results on when things changed. Remembering what I did with the server, I just changed that config file to:
HandlePowerKey=ignore HandleSuspendKey=ignore HandleHibernateKey=ignore HandleLidSwitch=ignore HandleLidSwitchDocked=ignore
That is, “let me configure this through the desktop, please”, and now I have my old behavior back :)
PS: I should start reading more about `systemd`. A good starting point seems to be all the links in its [home page](https://freedesktop.org/wiki/Software/systemd/).