Keeping a Mac awake and online
How to keep a Mac awake and online as a server: the sleep settings that hold, restart after a power cut, serve from the login screen, and a scheduled wake.
Sleep is the first thing to check
When a self-hosted service is intermittently unreachable and nothing in the logs explains it, the machine was almost certainly asleep. A Mac conserves power aggressively by default. That is right for a laptop and wrong for a server.
Preventing display sleep is not the same as preventing system sleep, and that distinction catches almost everyone out once. The screen going dark costs you nothing. The system sleeping takes every service with it.
Read the settings before you change them
pmset is the tool, and reading it first tells you whether you have a problem at all.
The settings in force right now
pmset -gThe same, but per power source. This is how a laptop looks correct on mains and still sleeps on battery.
pmset -g customThe line that matters
Look for sleep. Zero means never. Anything else is a countdown in minutes to your service disappearing.
Finding out what is holding the Mac awake
This one is less well known and solves the opposite problem. It lists every assertion currently preventing sleep and names the process responsible, which is how you find the app that has been keeping a machine awake for a week.
pmset -g assertionsThe settings a server wants
Each of these is a separate decision, and all of them need sudo. The -a flag applies the setting to every power source.
Never sleep the system. On its own, this is most of the fix.
sudo pmset -a sleep 0Laptops only. Stops a closed lid from sleeping the machine, which sleep 0 alone does not prevent.
sudo pmset -a disablesleep 1Desktops only, and the most valuable line here: start again by itself after a power cut.
sudo pmset -a autorestart 1Let an incoming connection wake a machine that did sleep. A safety net, not a plan.
sudo pmset -a womp 1Stop the scheduled low-power wake-ups a server does not need.
sudo pmset -a powernap 0Let the screen sleep. It saves power and changes nothing about what is running.
sudo pmset -a displaysleep 10Confirm it, do not assume it
Read the values back. A setting that did not take is the failure mode here, and it fails quietly: the machine goes on sleeping while you believe it cannot.
pmset -g | grep -E 'sleep|autorestart|womp'For a one-off, do not change anything
caffeinate holds the machine awake without touching your settings, which is what you want while a long job runs.
Awake until you stop it with Ctrl-C
caffeinate -dimsuAwake only while that command runs
caffeinate -i ./long-running-job.shPower, and the laptop question
A Mac serving on battery will sleep when it runs low no matter what you configured, so anything always-on needs to stay plugged in. On a laptop that raises a fair question about holding a battery at full charge for months, which recent macOS handles better than it used to. A mini sidesteps the question entirely.
Decide what should happen after a power cut. autorestart 1 covers the machine coming back. It does not cover the ten minutes of downtime, or a router that takes longer to boot than the Mac does.
A scheduled wake, as a backstop
You can also schedule power states. This wakes or powers on the machine every morning, which is a reasonable safety net for a server that is meant to be permanent and occasionally is not.
sudo pmset repeat wakeorpoweron MTWRFSU 06:00The login nobody plans for
Services that run as your user need that user to be logged in. After a restart, a Mac sitting at the login window is running almost nothing.
This is the difference between a LaunchAgent and a LaunchDaemon, and it is worth knowing which yours is.
- A LaunchAgentRuns inside a user's login session. It waits for somebody to log in, which means it does not exist during an unattended reboot.
- A LaunchDaemonRuns at boot, as root, with no session at all. If your service has to survive a restart nobody is present for, it has to be one of these.
FileVault changes what a reboot means
FileVault makes the login stricter still. The disk stays encrypted until somebody types a password at the pre-boot screen, so nothing starts before then: not daemons, not networking, not SSH.
That is not a reason to turn it off on a machine sitting in your home. It is a reason to know that an unattended reboot on an encrypted Mac needs a person in the room.
The one way to reboot remotely
This authenticates now and restarts once without needing the password at boot, which makes a planned reboot such as a macOS update safe to do from somewhere else. It does nothing for an unplanned one.
sudo fdesetup authrestartNetwork: what a server actually needs
Use Ethernet if the machine can reach a cable. Wi-Fi is fine for a laptop that browses. A server answering several devices at once does better on a wired connection that does not renegotiate, roam, or share airtime with a microwave.
Give it a fixed address on your own network too, either a static one or a DHCP reservation on the router. A server whose local address moves breaks every port-forwarding rule pointing at it, and it will do that on the day the router reboots rather than on the day you set it up.
What still fails after all of this
No amount of configuration solves a power cut, a provider outage, a macOS update that reboots overnight, or somebody unplugging the machine to charge a phone. A Mac at home has an uptime ceiling set by your flat, and tuning does not raise it.
The useful move is to make failures loud instead of pretending they will not happen.
- Monitor from somewhere else. A check running on the same machine tells you nothing at the moment that machine is the problem.
- Make the alert say which layer failed, not just that something did.
- Decide in advance what you will actually do about it, because an alert you ignore twice is an alert you have stopped reading.
Knowing which thing broke
MacServe reports only what it can see: whether the Mac checked in, whether Linux is running, whether the tunnel is connected. Then it names which one is wrong, instead of showing a single unexplained error.