freedzhost.cloud

Sleep when idle, wake on demand: the energy recipe

Level IntermediateEstimated time 45 minRead first Homelab 1: Proxmox, the base under every serviceA word you don't know? Glossary

A tower with two large graphics cards draws far more than a small server, even idle. Ours sleeps whenever nobody needs it. A small machine that is on anyway (the Proxmox node of Homelab 1) wakes it up on demand, and the wake command only returns when the tower is really ready to work.

Phone or laptopanywhere, via tailnetAlways-on nodesmall, low powerThe towerasleep → awakewake commandmagic packet (LAN broadcast)ready = SSH + gateway answer
The big tower sleeps. A small machine that is always on sends the magic packet on the local network; the tower wakes, and the wake command waits until SSH and the model gateway really answer.

A bit of history

Wake-on-LAN goes back to the mid-1990s: AMD's "Magic Packet" is a network frame carrying the target's hardware address repeated sixteen times. A sleeping network card keeps listening for it and powers the computer on. Thirty years later, the same packet lets a home server sleep most of the day and wake the moment you need it.

1. Allow the wake-up

  1. In the firmware (BIOS): enable Wake on LAN (sometimes Power On By PCI-E), and disable deep power-saving modes such as ErP, which cut power to the network card.
  2. Use the wired network card: Wake on LAN does not work over Wi-Fi on ordinary hardware.
  3. Check, then make it permanent with NetworkManager: 
    sudo ethtool <interface> | grep Wake-on      # "g" means magic packet
nmcli connection modify <connection> 802-3-ethernet.wake-on-lan magic
  4. Note the card's hardware (MAC) address: ip link show <interface>. Keep it in your notes, not in a public file.

2. Send the magic packet from inside

The magic packet is a broadcast on the local network: it has to leave from a machine on the same network. Use the small always-on machine:

wakeonlan <MAC address>    # or: etherwake, or a web dashboard such as UpSnap

From outside, reach that small machine through your private network (Tailscale, WireGuard), then send the packet from there.

Never forward Wake on LAN from the internet through your box: anyone could switch your machine on, and you gain nothing over a private network.

3. "Awake" is not "ready"

A machine that answers ping may still be starting its services. Our wake command waits for two real answers before it returns: an SSH connection, then the model gateway's health check. Only then do the agents get the green light. Three minutes without an answer is a failure, reported as such.

4. Go back to sleep

systemctl suspend puts the tower to sleep. Decide when it sleeps on real signals, not idle input: a one-minute timer (gamer-idle-watch) checks for an established SSH connection and a running game (the same probe the GPU-mode switch uses); fifteen minutes with neither, it asks sleep-gamer to suspend. sleep-gamer itself refuses — timer or not — while a job is queued or a runner is alive, so the automatic path cannot cut work in flight; it only ever suspends, never powers off, which stays a choice made by hand.

The trap that kept surprising us

Our tower kept falling asleep in the middle of remote work, exactly fifteen minutes after each wake-up. The cause was not our session but the login screen: its default settings suspend after 900 seconds without local keyboard or mouse activity, and SSH, remote desktops or model requests never reset that timer. The more we worked remotely, the more it slept. The fix: give the login screen its own setting (on GNOME, a dconf profile for gdm with sleep-inactive-ac-type='nothing') and keep the decision to sleep in your own hands. Its signature is arithmetic: if the tower always sleeps exactly 15 minutes after waking, look nowhere else.

Sources

Found this useful? Tell us what to measure next.