Edit: Thanks for all suggestion! In my case (Thinkpad) I managed to make it persistent via udev, as described here.
It looks like there was a pre-existing udev configuration about this, but had slightly wrong SUBSYSTEM and DRIVER parameters:
- old:
SUBSYSTEM=="acpi", DRIVER=="button" - correct (in my case):
SUBSYSTEM=="platform", DRIVER=="acpi-button"
maybe because of some recent systemd changes?
Hope this may help others.
I have Kubuntu on a Thinkpad, and a S3-sleep state selected in the Bios.
My setup has always been to not resume from sleep when the lid is open. I achieved this by running once
echo "LID" | sudo tee /proc/acpi/wakeup
which toggles the wakeup-on-lid state. The behaviour would be respected upon restart.
Here’s my problem: since some recent update – I don’t know whether from apt or fwupd – I discovered that the laptop was waking up upon lid opening. So I issued the command above again. It works, but it gets reset upon restart, unlike before.
Anyone has good tips on how to make this setting permanent?
In the Bios I didn’t find any settings about this.
Cheers!
I’m certain you can do this with a udev rule. I used something simmilair to prevent my laptop from waking when the screen flexes on the keyboard wile it is in a bag.
This article in the arch wiki might be helpful: https://wiki.archlinux.org/title/Power_management/Wakeup_triggers
You can try to set
HandleLidSwitch=ignoreevent defined in/etc/systems/logind.conf. That will definitely prevent the laptop from sleeping on lid close. It might also prevent the laptop from waking on lid open.Regardless, I suggest hunting down what broke that setup recently. Its probably some new daemon is responsible for configuring those events in a less arcane way.
Thank you. In my case, unfortunately, changing the
HandleLidSwitch*options didn’t work. Luckily changingudevsettings did the job!Just for completions sake. Did you change them all?
There’s
HandleLidSwitch,HandleLidSwitchExternalPowerandHandleLidSwitchDockedEdit: Oh, I did missed the “*”. So assume that is a yes.
Yes, all three. Also tried adding these options in a separate file in
logind.conf.d/. Some searches on StackExchange show that this worked for some, indeed.
You could just drop the line into a script (without the sudo) into
/usr/local/bin/and call it on startup.If you use systemd it’s as simple as:
[Unit] Description=Disable Lid Suspend [Service] Type=oneshot ExecStart=/usr/local/bin/lid-suspend [Install] WantedBy=basic.targetJust drop it into
/etc/systemd/system/lid-suspend.serviceand then callsudo systemctl daemon-reloadandsudo systemctl enable lid-suspendThank you for this!🙏 I was going this way, but found that some
udevconfig may need change, see update to post.
I would assume your system is using systemd (I don’t use Kubuntu specifically); the laptop lid is (now in 2026) controlled by the systemd infrastructure - it’s a matter of setting a config option and this should fix you up. Arch as usual has the best wiki on the subject:
https://wiki.archlinux.org/title/Power_management#ACPI_events
You’re probably looking at
HandleLidSwitch*options. There’s still nothing wrong with the manual disable to/proc/acpi/wakeupto cover your bases (layers of the onion), I’m fighting with a “modern” laptop that only has s2idle and it’s terrible compared to S3 - I’m in ACPI wakeup hell and still trying to figure out what’s causing it.Thank you for this 🙏. I tried the
HandleLidSwitch*options, setting them all to “ignore”, but unfortunately it didn’t work in my case. Adding or modifyingudevrules luckily did!
This reminds me of the new trend of kids breaking hinges and propping laptops open with fruit or whatever so they can keep AI running without “sleep” or “wake”
The solution?
Dunno. Just wanted to share my thoughts
My laptop’s lid doesn’t have hinges, that’s part of the problem. But besides that, it’s simply something I don’t want. For me it’s enough if the power button and the “Fn” button wake up the laptop.
It’s just a toggle related to your screen being on/off… depending on your flavour of Linux, nay… regardless; someone will have a patch.
This conversation helps bring eyes onto this post. One of these kind travelers will have the solution and even provide a link.







