Managing suspend and resume on elementary OS
Sliding a laptop closed at a busy Melbourne café before ordering another flat white is something most Australian laptop owners do without thinking. The machine hums quietly, the screen dims, and a few minutes later the lid lifts to reveal the desktop exactly as it was. That everyday ritual rests on a feature rarely discussed in polite company: the suspend and resume cycle.
elementary OS treats suspend as a normal part of life rather than a power-user toggle. Because the desktop sits on top of a fairly vanilla Linux kernel and uses systemd's logind to track user sessions, the distribution inherits a sensible default behaviour that works on most hardware sold through Australian retailers. Closing the lid on a Dell XPS bought from JB Hi-Fi, a Lenovo ThinkPad sourced through your workplace, or a refurbished Framework from an Adelaide swap meet will, in the majority of cases, send the machine straight into Suspend-to-RAM. Opening the lid wakes the session within a second or two, network reconnects automatically, and any unsaved documents stay exactly where they were.
This piece walks through how those defaults are wired together, where they can be tuned, and what to do when they misbehave. It also touches on hibernate, lid behaviour, battery drain during long naps, and the small handful of commands worth keeping handy for diagnosis. If you are newer to the platform and still exploring the bundled applications, the AppCenter has a dedicated productivity collection that pairs well with a tidy power profile — see the AppCenter guide for some starting points.
How elementary OS handles suspend by default
Underneath the Pantheon shell, suspend is initiated by logind whenever the system thinks the user has stepped away. The two most common triggers are closing the lid and pressing the power button. Both actions are caught by the daemon, which then asks the kernel to write the contents of working memory into RAM and halt most of the hardware. The system stays in this low-power state — usually drawing between 0.5 and 2 watts on a typical ultrabook — until something rouses it: a keystroke, a mouse wiggle, a network packet, or the lid lifting.
elementary OS ships with sane defaults that match the expectations of users in Australian workplaces, where closing the laptop during a meeting is a near-universal cue that the speaker is done. Out of the box, lid close on battery triggers suspend, lid close on AC power does nothing, and the power button shows a small dialog offering shutdown, restart, or lock. These behaviours come from a combination of systemd's handle-lid-switch parameter and the dconf settings exposed through the Power pane in System Settings.
You can inspect what your machine is actually doing with a quick terminal command. journalctl -b | grep -i suspend lists every suspend and resume event from the current boot, including the kernel timestamp and the triggering cause. cat /sys/power/mem_sleep reveals whether the kernel supports modern s2idle (Suspend-to-Idle) or the deeper S3 sleep state — important context if a particular laptop refuses to stay asleep.
Toggling lid behaviour and button actions
The graphical Power pane in System Settings only exposes a few options, but the underlying configuration is broader and worth knowing about. Lid behaviour lives in /etc/systemd/logind.conf and can be overridden per-user by dropping a drop-in snippet into /etc/systemd/logind.conf.d/. Setting HandleLidSwitch=suspend keeps the default; HandleLidSwitch=lock simply locks the screen without sleeping; and HandleLidSwitch=ignore lets the lid do nothing at all, which is occasionally useful if your laptop lives on a stand with an external monitor and you only ever close the lid for travel.
Power button behaviour follows the same pattern through the HandlePowerKey directive. Many Australian users who dock their machines at work prefer HandlePowerKey=lock so that an accidental tap on the power button does nothing more dramatic than blanking the screen. Anything more aggressive — poweroff, reboot — is best avoided because it bypasses the careful session state that elementary OS maintains.
A quicker, less permanent route uses the dconf database directly. Opening dconf-editor and navigating to org.gnome.settings-daemon.plugins.power lets you tweak the lid-close actions separately for battery and AC power, change the idle delay before the screen blanks, and disable the critical-battery auto-suspend if you find it kicking in too early. The Australian summer, particularly in Brisbane and Perth where afternoon temperatures regularly push past thirty-five degrees, can cause some laptops to misreport battery levels and trigger that critical threshold prematurely, so a small dconf tweak may save you from an unexpected shutdown in the middle of a video call.
Hibernate as a power-saver alternative
Suspend-to-RAM is fast and convenient, but it is not free. A laptop left asleep in a travel bag for two weeks can emerge with a flat battery, which is a particular nuisance for anyone catching the Overland from Adelaide to Darwin or storing a machine in a holiday house over the Christmas break. Hibernate addresses this by writing the contents of RAM to the swap partition and powering the machine down completely. Waking from hibernate is slower than waking from suspend — usually ten to twenty seconds on a spinning disk and around five on NVMe — but no power is consumed while the lid is closed.
elementary OS does not enable hibernate by default, and enabling it requires a small amount of preparation. The swap partition or swap file must be at least as large as the installed RAM, the kernel must be booted with resume= and resume_offset= parameters pointing at the swap device, and the initramfs must be regenerated afterwards. Users on recent kernels (5.15 and later) who have plenty of disk space can instead use hibernate mode inside systemd, which simplifies a lot of the plumbing.
Once hibernate is working, you can swap the lid-close action over to hibernate rather than suspend by editing the logind drop-in or by using a small script bound to the power button through Settings → Keyboard → Shortcuts. Long-haul flyers in and out of Sydney and Melbourne often prefer this arrangement, since it makes it safe to leave the machine packed away for the entire flight without the worry of a deeply discharged battery on arrival.
Diagnosing wake and resume glitches
When a laptop refuses to wake, fans spin wildly on resume, or wireless networking disappears after a sleep cycle, the answer is almost always in the logs. The Australian Cyber Security Centre recommends keeping device logs enabled for incident response, and the same advice applies to diagnosing personal hardware quirks. Running journalctl -b -1 | grep -E "suspend|resume|PM:" immediately after waking prints the relevant kernel messages from the previous boot, which often point at a misbehaving driver.
Three culprits cause most resume problems on elementary OS. The first is the wireless card, especially Intel AX series chips that occasionally lose their firmware after deep sleep. The second is the NVIDIA proprietary driver, which is notorious for failing to restore its memory map cleanly; users on hybrid graphics may need to disable the discrete card before suspending. The third is USB peripherals that send wake-up signals through a powered hub, waking the machine inside a bag.
A practical workaround for the wireless issue is to disable the suspend module of NetworkManager before sleeping and re-enable it on wake. A systemd user service with a sleep hook in ~/.config/systemd/user/ can call nmcli networking off before suspend and nmcli networking on after resume, which forces a clean state without the need for a reboot. For the NVIDIA scenario, elementary OS users in Australian gaming communities often pair the open kernel modules with a clean s2idle suspend, sidestepping the proprietary blob entirely.
Prolonging battery life while the lid is closed
Suspend draws roughly the same power as a switched-off appliance with a clock inside, but a handful of small habits can stretch that figure even further. Disabling wake-on-LAN in the BIOS saves a small but measurable amount of power, particularly on machines that spend long periods on a desk in Canberra offices where IT departments routinely send magic packets for patching cycles. Switching the SSD's link power management to the lowest aggressive state through hdparm -I /dev/sda | grep "power management" and setting SATA_ALPM to min_power in a udev rule can shave another tenth of a watt or so.
Modern kernels also support per-device runtime PM, which can be tuned through powertop. Running powertop --auto-tune once is a reasonable starting point, though it is worth reviewing each suggested change before letting it stick permanently. Some users in regional Western Australia, where the grid is less stable and summer blackouts are common, rely on these tunings to keep their machines asleep for the full duration of an outage without losing session state.
One last habit worth forming: shut the machine down completely at least once a week rather than relying on suspend indefinitely. Firmware updates, kernel patches, and the occasional full charge cycle all benefit from a clean boot, and elementary OS's fast boot times make the interruption barely noticeable. Run a full shutdown this evening, leave the lid open overnight so the battery can settle, and tomorrow morning you'll start with a fresh, predictable session that handles suspend exactly the way you expect.
