Kip CroninCreate a drop-in file in /etc/systemd/logind.conf.d/ with HandleLidSwitch=ignore, HandleLidSwitchExternalPower=ignore and HandleLidSwitchDocked=ignore under [Login], then reboot. Set all three: on AC power, the lid still follows HandleLidSwitch unless you set the external-power one too. Our laptop server then spent three days with its lid shut without suspending once.
This is the first step of turning an old laptop into a 24/7 Ubuntu server.
The fix
This is the file on our ThinkPad X1 Carbon Gen 7, in place since 15 May 2026:
# /etc/systemd/logind.conf.d/server-mode.conf
[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
IdleAction=ignore
logind.conf(5) recommends a drop-in in logind.conf.d/ over editing logind.conf, so a package update can't overwrite your change. It also gives the defaults:
HandleLidSwitchissuspend.HandleLidSwitchExternalPower"is completely ignored by default", so on AC the lid falls back toHandleLidSwitch.HandleLidSwitchDockedisignore. "Docked" includes having more than one display connected.IdleActionalready defaults toignore. We set it anyway so the file says everything in one place.
We applied it with a reboot rather than restarting systemd-logind underneath a running desktop.
Check it took effect
systemd-analyze cat-config shows the merged configuration files. Asking logind over D-Bus shows what it's actually using:
systemd-analyze cat-config systemd/logind.conf | grep -E '^[^#]*(Lid|IdleAction)'
for p in HandleLidSwitch HandleLidSwitchExternalPower HandleLidSwitchDocked IdleAction; do
echo -n "$p "
busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager $p
done
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
IdleAction=ignore
HandleLidSwitch s "ignore"
HandleLidSwitchExternalPower s "ignore"
HandleLidSwitchDocked s "ignore"
IdleAction s "ignore"
The proof: before and after
A setting isn't proof, but logind logs every lid event, so the journal already has the test. This is the same laptop on 11 February, before the change. The lid closes, it suspends, wakes about 45 seconds later and suspends again, for as long as the lid stays shut:
journalctl -u systemd-logind -o short-iso --grep 'Lid (closed|opened)|Suspending|will suspend|Operation .suspend. finished'
2026-02-11T11:00:41+02:00 x1 systemd-logind[978]: Lid closed.
2026-02-11T11:00:41+02:00 x1 systemd-logind[978]: Suspending...
2026-02-11T11:01:27+02:00 x1 systemd-logind[978]: Operation 'suspend' finished.
2026-02-11T11:01:52+02:00 x1 systemd-logind[978]: Suspending...
2026-02-11T11:02:36+02:00 x1 systemd-logind[978]: Operation 'suspend' finished.
And this is every lid or suspend line after the drop-in went in and the machine rebooted at 09:26 on 15 May:
-- Boot 85dad5b508e74b92932c4750640dcb2a --
2026-05-15T19:00:19+03:00 x1 systemd-logind[1012]: Lid closed.
2026-05-18T18:35:08+03:00 x1 systemd-logind[1012]: Lid opened.
2026-05-18T18:35:09+03:00 x1 systemd-logind[1012]: Lid closed.
Closed on Friday evening, opened on Monday evening, and no Suspending... in between. While the lid was shut, the laptop's daily timer started its job at 09:00:06 on each of the three mornings:
2026-05-16T09:00:06+03:00 x1 systemd[1691]: Starting <our daily job>.service...
2026-05-17T09:00:06+03:00 x1 systemd[1691]: Starting <our daily job>.service...
2026-05-18T09:00:06+03:00 x1 systemd[1691]: Starting <our daily job>.service...
Unit name redacted; the rest is verbatim.
One more check: the monotonic clock pauses during suspend (systemd.timer(5)). That boot's journal ends at 387,862 monotonic seconds, which is 4 days, 11 hours and 44 minutes. That's the same as the wall-clock time from 09:26:28 on 15 May to 21:10:55 on 19 May, so the machine didn't sleep at all during that boot.
[387862.795855] x1 systemd-journald[332]: Journal stopped
2026-05-19T21:10:55.425955+03:00 x1 systemd-journald[332]: Journal stopped
What the log can't tell us is whether the laptop was plugged in during those three days. Our drop-in sets both the battery and the AC case to ignore, but this history doesn't show which one logind used.
When the setting is ignored
The man page has one big exception: a program can take a handle-lid-switch inhibitor lock, and then logind does nothing on the lid at all, whatever the config says. Desktop environments use this to handle the lid themselves. List the locks:
systemd-inhibit --list
WHO UID USER PID COMM WHAT WHY MODE
ModemManager 0 root 1161 ModemManager sleep ModemManager needs to reset devices delay
NetworkManager 0 root 1102 NetworkManager sleep NetworkManager needs to turn off networks delay
UPower 0 root 2255 upowerd sleep Pause device polling delay
Unattended Upgrades Shutdown 0 root 1647 unattended-upgr shutdown Stop ongoing upgrades or perform upgrades before shutdown delay
GNOME Shell 1000 x1 2774 gnome-shell sleep GNOME needs to lock the screen delay
x1 1000 x1 3003 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses block
x1 1000 x1 3003 gsd-media-keys sleep GNOME handling keypresses delay
x1 1000 x1 3010 gsd-power sleep GNOME needs to lock the screen delay
8 inhibitors listed.
GNOME 46 blocks the power, suspend and hibernate keys, but nothing holds handle-lid-switch here, so logind's ignore is what counts. We captured this with no external display connected; we haven't checked whether that changes with one.
The lid isn't the only way it sleeps
This stops lid-triggered suspend only. Idle suspend is separate: GNOME has its own timers, and the login screen has its own session. On our machine we also masked the sleep targets, so suspend can't start at all. That's step 2 of the always-on laptop checklist.