A resident system must respond whenever you connect. That means the machine must stay awake. Yet every machine is designed to sleep by default to save power. This chapter blocks sleep in four layers and checks that the machine is awake through both visible settings and the command line.
§ 00 · Staying Awake Comes First
You try to connect from outside, but the machine does not respond. This is the most common first frustration in remote development. Nine times out of ten, the machine is asleep.
A laptop is built to sleep. Close the lid and it sleeps; leave it untouched and it sleeps. That is a virtue for saving power. But for a resident system, sleep is a defect, not a virtue. If you reach for it from afar and it is asleep, it has already ceased to be a system.
The first task is therefore clear: keep the machine awake. And, more importantly, verify that it is awake rather than believe it is. Do not trust that one switch in a settings screen has finished the job. In remote work, belief is a luxury.
| Distinction | What happens | Effect on remote work |
|---|---|---|
| Display off | Only the monitor rests—it merely saves power | None—remote work continues even with the display off |
| System sleep | The entire machine stops | Fatal—you cannot connect from outside. This is what we prevent. |
§ 01 · Four Layers Against Sleep
There is more than one way to prevent sleep. Rely on just one, and when it disengages, the machine quietly falls asleep. So we stack layers. With the following four, the next layer supports you when one gives way.
Two layers of visible settings and two invisible command-line layers. Just remember that turning the display off and putting the machine to sleep are different things. The display may turn off. As long as the machine stays awake, remote work continues.
1 · System power settings (GUI) · The first place to adjust. Set system sleep to “Never” and allow only the display to turn off. The machine runs continuously; the display saves power. Separating these two is the key.
2 · Resident sleep-prevention app (GUI) · If settings alone leave you uneasy, run a tool that continuously prevents sleep from the screen. A visible safety net you can switch on or off with one click.
3 · Command-line sleep inhibition (terminal) · A script can also prevent sleep. For long unattended work such as builds or deployments, it holds off sleep only while that task is alive. It is independent of the GUI, adding a second restraint.
4 · Wake on network activity (terminal) · A setting that wakes the machine when a remote connection arrives, even if it happens to fall asleep. Preventing sleep and waking it if it does sleep: set both and leave no blind spot.
§ 02 · Do Not Believe; Measure
All the settings are in place. Is the machine awake now? This is where most people stop: the settings are applied, so it must be fine. In this methodology’s language, that is a confession, not evidence.
The evidence is in the command line. Ask directly about power-management state, and the machine answers in numbers whether it is set to sleep, whether only the display will turn off, and what is preventing sleep. I asked and checked: system sleep set to “Never,” only the display saving power, sleep prevention actually active, and wake on network activity enabled. The screen is off, but the machine is fully running.
This attitude runs through the entire methodology. A switch in a settings screen is a promise to act; a command-line response is evidence of acting. Promises and evidence differ. People who sustain remote work do not trust promises; they measure evidence.
Read this note at sass.studio.