§ 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:

~/.config/autostart/ignore-lid-switch-tweak.desktop

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: lid-close-suspend-with-external-monitor.

Why is it hidden? There's no explicit flag for this on Gnome settings (or Gnome Tweaks).

This setting can be changed using dconf-editor (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 explicitly 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".

No luck.

§ 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 explanation 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.

Nope.

What's the problem with systemd not honouring the LidSwitchIgnoreInhibited setting?

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?

Almost.

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.