My old Samsung Q330 has a quiet life. It sits in the office, always on, running the web service that powers a small WordPress site and taking its backups on schedule – exactly the kind of setup I describe in LAMP Stack for Humans. But “always on” got me thinking: nobody visits that site at 3 AM. Why is the poor thing awake all night?
There’s a certain irony here: back in 2020 I wrote about teaching this very machine to never sleep when the lid is closed. Five years on, we’ve come full circle – now I want it to sleep, just on my terms.
It turns out Linux has had the answer built in all along, and it’s delightfully low-tech. The tool is called rtcwake, it ships with Fedora out of the box (it’s part of util-linux), and it lets a machine put itself to sleep and wake up again automatically – no add-ons, no daemons, no scratch-built scripts polling the clock.
The alarm clock soldered onto your motherboard
Here’s the part I find genuinely charming. Every PC motherboard has a real-time clock chip – the same one that keeps time while the machine is powered off. That RTC has an alarm register, a hardware feature that predates Linux entirely. It is, quite literally, an alarm clock soldered onto the board. When the alarm fires, the chip signals the chipset to power the machine back up. The operating system doesn’t need to be involved at all; the kernel can be fast asleep and the wake-up still happens, because it’s the motherboard doing the work.
All rtcwake does is set that alarm and put the machine to sleep in one motion. Here’s the simplest form:
sudo rtcwake -m mem -s 21600
This suspends the machine to RAM (-m mem) and programs the RTC to wake it again in 6 hours (21600 seconds). If you’d rather give it an absolute time, you can:
sudo rtcwake -m mem -t "$(date +%s -d 'tomorrow 10:00')"
The -m flag chooses the sleep state. mem is suspend-to-RAM: fast wake, tiny power draw. disk is hibernate: needs swap space and wakes more slowly, but draws zero power. For a nightly nap, mem is the one you want.
The two-minute test
Before trusting any of this on a machine you rely on, verify the hardware actually wakes. Some older laptops have quirky ACPI implementations, and the only way to know is to try. The test is one command:
sudo rtcwake -m mem -s 120
Walk away for two minutes and see if it comes back on its own. The Q330 passed on the first try – the screen went dark, and 120 seconds later it woke itself up as if nothing had happened. If your machine passes this test, you’re golden.
You can also confirm the alarm is armed by peeking at the RTC directly:
cat /sys/class/rtc/rtc0/wakealarm
If it holds a Unix timestamp, the alarm is set. If it’s empty, nothing is scheduled.
Making it a schedule with a systemd timer
A one-off nap is nice, but the goal is a routine. In my case: sleep at 8 PM, wake at 10 AM, every day, without me touching anything. That gives the Q330 fourteen hours of rest and ten hours of duty – and crucially, its nightly backup at 6 PM lands comfortably inside the awake window. You could do this with cron, but this is Fedora, so let’s be proper about it and use a systemd timer.
First, a small service unit that does the actual work. Create /etc/systemd/system/nightly-nap.service:
[Unit]
Description=Suspend until 10 AM via rtcwake
[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c '/usr/sbin/rtcwake -m mem -t "$(date +%%s -d 10:00)"'
Note the doubled percent sign in %%s – systemd uses % for its own specifiers, so it needs escaping inside unit files. Also note that since the service runs at 8 PM, date -d 10:00 would resolve to 10 AM this morning – a time in the past. Happily, we can sidestep the issue entirely by asking for tomorrow explicitly:
ExecStart=/usr/bin/bash -c '/usr/sbin/rtcwake -m mem -t "$(date +%%s -d \"tomorrow 10:00\")"'
Then the timer that triggers it. Create /etc/systemd/system/nightly-nap.timer:
[Unit]
Description=Nightly nap at 8 PM
[Timer]
OnCalendar=*-*-* 20:00:00
Persistent=false
[Install]
WantedBy=timers.target
Enable and start the timer, and you’re done:
sudo systemctl daemon-reload
sudo systemctl enable --now nightly-nap.timer
systemctl list-timers nightly-nap.timer
One deliberate choice here: Persistent=false. The persistent option tells systemd to “catch up” on missed timer runs at boot. For most timers that’s helpful, but for this one it would mean the machine suspends itself moments after you wake it up mid-morning because it missed last night’s run. Not what we want from a nap schedule.
What sleep means for your services
Suspend-to-RAM means genuinely offline. During the nap window there is no web server, no WordPress, no backups firing. That has two practical consequences worth thinking through:
First, schedule your other timers inside the awake window. If your backup runs at midnight, it simply won’t happen – the machine is asleep and no amount of systemd persistence will run a job on a suspended kernel. Mine fires at 6 PM, two hours before bedtime, so it always completes with room to spare. If yours runs overnight, move it into working hours before enabling the nap schedule.
Second, anything external that polls the machine – uptime monitors, search crawlers – will see it dark overnight. For a personal or office WordPress with confidential data that nobody visits at 3 AM, I’d argue that’s a feature, not a bug: the machine is unreachable and unattackable for most of the day. An attack surface that doesn’t exist is the best kind.
One more refinement for laptops on Wi-Fi: if NetworkManager takes a moment to reconnect after resume, a small resume hook can give it a nudge. A oneshot service with WantedBy=suspend.target and After=suspend.target will run automatically on wake – a good place for an nmcli connection up or a quick connectivity check.
Conclusion
An always-on server doesn’t have to be always on. The hardware to wake a sleeping machine on schedule has been sitting on every motherboard for decades, and Linux has shipped the tool to use it all along. Two small unit files later, my Q330 now gets fourteen hours of rest a day – which, after sixteen years of service, it has thoroughly earned. Give the two-minute test a try on your own hardware; you might be pleasantly surprised.