§ Part I: setting the basic suspend
You can access the power management from the Gnome settings and set the computer to suspend after a delay (both on battery and on AC).
Set them to your preference and now the laptop should always suspend after the delay you've set.
One more thing: there's a separate setting to configure the "close lid" action.
Once, it was right with the Power settings, but at some point it has been removed.
Oh wait, it was not removed. Just moved to a place that only the Tweak companion utility can reach:
As a side note, I've discovered in the ArchLinux wiki that this setting, when set to false, creates this file:
a "drop-in" configuration file that will trigger the Gnome Tweaks inhibitor. Well ... wow.
§ Part II: the external monitor
I soon realize that this is just partially what I need: I have an external monitor attached and this seems to be a completely different can of worms.
The external monitor is blocking the suspend feature. Well, one can argue that it makes sense: you might want to attach an external keyboard+monitor to a laptop, close the lid, put it away in a corner and keep on working.
On the other hand, I'd like the laptop to always suspend immediately when I close the lid, with or without an external monitor attached.
After some research, I discover a hidden Gnome setting:
Why is it hidden? There's no explicit flag for this on Gnome settings (or Gnome Tweaks).
This setting can be changed using
apt install dconf-editor):
$ dconf-editor org.gnome.settings-daemon.plugins.power
Then look up
lid-close-suspend-with-external-monitor, its default is false. Set it to true.
So, not only this setting if not actionable in a "user-friendly" way, not even using Gnome Tweaks, but also it looks to be undocumented. I've found a reference on a Ubuntu Mate forum after throwing some random keywords at DuckDuckGo. And only after - now I knew what to look for - I've found it referenced in other places too. I was not able to find a reference in any Gnome documentation. And, in my opinion, this is not good.
While the majority of people were complaining that their laptop suspended when they closed the lid, this is exactly the behaviour I was looking for, se let's set
lid-close-suspend-with-external-monitor to false.
It doesn't work.
If I unplug the monitor or explicity request to suspend, it suspend-on-lid-closing works. With the external monitor attached, no way. *sigh*.
Let's apply some more DDG-fu. Uhm ... more people complaining about this. I also see floating keywords such as systemd, nvidia, bugs ... *groan*, I should have seen this coming.
This answer on askubuntu.com suggests a problem with the nVidia chipset (ah-ah, so Linus was right?). That was in 2015, will they have fixed by now? I disable the nVidia chipset altogether with
nvidia-settings and switch to the FOSS nouveau driver from Ubuntu "Software & Update".
§ Part III: following systemd bloody trail
Here there's a thorough bug report that teaches me how to edit the
logind configuration, followed by a convoluted explaination by Poettering on why systemd's behaviour is correct and passes the buck to the Gnome folks. The main getaway in this GitHub issue, however, is the line that allows you to inspect what systemd is blocking and why:
$ systemd-inhibit --list --mode block ... Who: me (UID 1000/me, PID 1393/gsd-power) What: handle-lid-switch Why: Multiple displays attached Mode: block ...
now I understand what's really happening and what to investigate.
Something's blocking the
handle-lid-switch action. I need to get rid of those "
block"s. I feel I'm just some DDG-searches from the solution.
Following this systemd issue, I decide to bite the bullet and dive into the systemd configuration and
logind.conf documentation (
man 5 logind.conf), changing the following:
HandleLidSwitch=suspend HandleLidSwitchDocked=suspend LidSwitchIgnoreInhibited=no
Restart systemd logind service with
sudo systemctl restart systemd-logind.
What's the problem with systemd not honouring the
According to this ArchLinux forum thread there's a Gnome bug that inhibits the suspend on lid closing. I'm not commenting further that thread.
Next hint retrieved from another issue, this time on Fedora: apparently there's a patch for this! I'm getting closer, I can feel it.
Unfortunately that thread says that the patch didn't make it to Bionic Beaver, BUT a workaround disables all lid management done by Gnome:
Edit /etc/UPower/UPower.conf Change the setting IgnoreLid=false to IgnoreLid=true
YES, it worked!
Ok, so ... all is well what ends well, right?
As a addendum, I've discovered some interesting things preventing suspend/sleep in Ubuntu. Aside the aforementioned 'handle-lid-switch', there are other applications blocking it.
I use Rambox to keep together instant messenger (IM) applications; some of them have a desktop client that is nothing but a tethered session with the smartphone. When using Rambox, this session between the two devices seems to be blocking the suspend/sleep. It took me a while to narrow down the culprit, only to realize that happened when opening a session with Threema; here's what we see using our new cool new trick we've learned:
$ systemd-inhibit --list --mode block ... Who: me (UID 1000/me, PID 2919/gnome-session-b) What: shutdown:sleep Why: user session inhibited Mode: block ...
You'll need to close the session in order to cut the leash and be able to suspend your laptop. This does not happen if I use the plain browser.
§ Part IV: final thoughts
I can only be thankful to the generosity of the collective mind, a whole lot of people, whom each bit of hint allowed to move me an inch forward to the solution, allowing me to understand and (possibly fix) the issue at hand.
Complex projects not talking to each other, bad design decisions, then reverted, half-assed documentation. Volunteers doing what they can to help, sometimes doing what they want. This year will never be the year of Linux, until stuff like that persists.