Keeping an Ubuntu 25.10 Laptop Awake as a Lid-Closed vLLM + eGPU Server

How three layers of Ubuntu’s power management each had to be defeated — and why “obviously the WiFi power save” was the wrong guess.

My setup

An old laptop, lid closed, sitting on a shelf with an eGPU attached. It runs a vllm server that my other machines on the LAN may hit for a small agentic workflow. My requirement was simple: the box has to stay reachable over WiFi, indefinitely, with the lid closed.

On Ubuntu 25.10 with GNOME, that turned out to require fixes in three independent places.

The story, in three failures

Failure 1: lid close → suspend

Out of the box, closing the lid suspended the laptop. GNOME’s power daemon owns this policy on a desktop session, so editing logind.conf alone was not enough — I needed gsettings:

gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'
gsettings set org.gnome.settings-daemon.plugins.power power-button-action 'nothing'

Closing the lid no longer suspended the machine. vLLM stayed up.

But a ping from another LAN host showed ~30% packet loss, with latency swinging between 1 ms and 140 ms. Every 5–10 seconds, connectivity stuttered.

Failure 2: WiFi power save (a red herring)

dmesg looked clean — the card authenticated and associated normally. The latency variance looked like classic WiFi power-save behavior, so I tried NetworkManager's default first:

# /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
[connection]
wifi.powersave = 2

Values: 2 = disable, 3 = enable. Then:

sudo systemctl restart NetworkManager
iw dev wlp9s0 get power_save   # Power save: off

This did not fix the packet loss. I kept the change anyway — leaving WiFi power save on a headless server felt like a bad default — but it was not the cause.

Failure 3: the system was suspending on its own

I looked at journalctl again and saw this:

systemd[1]: Starting systemd-suspend.service - System Suspend...
systemd[1]: Reached target sleep.target - Sleep.
systemd[1]: Starting nvidia-suspend.service - NVIDIA system suspend actions...

The laptop was suspending every few minutes on its own. Quick fix — mask the sleep targets so systemd refuses to enter them no matter who asks:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Packet loss went to zero immediately, and the laptop has stayed online continuously since.

Final configuration

Three layers, three fixes. I needed all of them.

1. GNOME power policy — stops the desktop session from requesting suspend:

gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'
gsettings set org.gnome.settings-daemon.plugins.power power-button-action 'nothing'

2. NetworkManager WiFi power save — good hygiene for a headless server; was not the cause of loss in my case but I kept it on:

# /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
[connection]
wifi.powersave = 2

sudo systemctl restart NetworkManager

3. Mask the sleep targets — the actual fix:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

How I verified

# Should print nothing new over several minutes
journalctl -fb | grep -iE "suspend|sleep.target"

# WiFi power save off
iw dev wlp9s0 get power_save

# Ping from another host on the LAN — I now get ~0% loss
ping -c 200 <laptop-ip>

If I ever want to go back

Notes I left in my scratchpad for future me, in case I want this laptop to behave like a laptop again:

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
sudo rm /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
gsettings reset org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
gsettings reset org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type
gsettings reset org.gnome.settings-daemon.plugins.power power-button-action

Takeaway

Two things I’m taking away from this. One: on a modern Ubuntu desktop install, “don’t sleep” is not one setting — it’s a chain of three independent subsystems (GNOME power daemon, NetworkManager WiFi power save, systemd sleep targets) that each have their own opinion about what an idle laptop should do. Two: WiFi packet loss with high latency variance is not always power save — a suspend/resume loop produces the same symptom, and journalctl -b | grep -i suspend is the cheapest way to rule it out before chasing radio settings.