rtcwake and Scheduled Wakeups: Reactivating Servers and Desktops on Time

1. What rtcwake is for: power management meets scheduling

Classic scheduling with cron or systemd timers assumes the machine stays powered on continuously. For many use cases that is unnecessary: a home server that only needs to run a backup at night, a test rack that only needs to be active for scheduled test runs, or an energy conscious desktop that should not keep running between usage periods all benefit from spending most of the time in an idle state. This is exactly where rtcwake comes in, combining suspend states with a precisely scheduled wakeup time.

The basic idea: instead of a continuously running system that triggers a task via a timer, rtcwake actively puts the machine into a power saving state while simultaneously programming an alarm in the hardware clock that reliably wakes the system back up, even while the processor executes no instructions during the idle state. That significantly reduces power consumption and wear without having to give up scheduled tasks.

2. How rtcwake works: RTC alarm and ACPI wakeup

Technically, rtcwake uses a feature that many RTC chips offer in addition to pure timekeeping: a programmable alarm that triggers an interrupt signal at a specified time. This signal is caught by the kernel's ACPI subsystem and, depending on the power saving state, used to wake the system from suspend to RAM, suspend to disk, or another idle state, regardless of whether the processor itself is still active.

The process happens in two steps: first rtcwake writes the desired wakeup time into the wakealarm attribute of the RTC under /sys/class/rtc/rtc0/wakealarm, then it initiates the actual transition into the desired power saving state. Once the RTC reaches the programmed time, it generates a wakeup event that puts the hardware back into an active state via ACPI, after which the kernel continues the normal boot or resume process.

# Check whether the RTC supports wakeup alarms at all
cat /sys/class/rtc/rtc0/wakealarm

# List devices that can wake the system, and whether wakeup is currently enabled
cat /proc/acpi/wakeup 2>/dev/null || echo "acpi wakeup interface not available"

3. Basic usage: modes, time values, and options

The rtcwake command supports several suspend modes via the -m option. mem stands for suspend to RAM, the most power efficient state with fast wakeup, disk for hibernation, where the state is written completely to disk and the machine can then remain fully powerless afterward. The no option only programs the alarm without actually initiating a suspend state, which is very useful for testing and diagnostics.

The target time can be specified either relatively via -s seconds or absolutely via -t Unix timestamp. In practice, the relative form is usually more intuitive, while the absolute form is better suited for generated scripts that compute a fixed target time. The --verbose option additionally prints detailed information about the calculated wakeup time and the chosen mode, which is especially valuable for diagnostics during the initial setup.

# Suspend to RAM for 30 minutes, then wake automatically
sudo rtcwake -m mem -s 1800

# Suspend until a specific Unix timestamp (useful for generated scripts)
target_ts=$(date -d "tomorrow 06:00" +%s)
sudo rtcwake -m mem -t "$target_ts"

# Only program the wake alarm, without actually suspending (useful for testing)
sudo rtcwake -m no -s 60 --verbose

4. Use cases: backup windows, energy savings, test racks

The classic use case is a home server or small office server that stays idle outside office hours and only wakes up for a nightly backup window. A script puts the server into a suspend state after hours with a programmed alarm for backup time, the backup runs, and afterward the server automatically returns to idle until regular operation resumes the next morning.

A second common case is hardware test infrastructure, where many physical test racks only need to be active for scheduled, automated test runs. Instead of leaving dozens of machines running continuously, a central scheduler wakes each machine shortly before its scheduled test run via rtcwake, which noticeably reduces energy costs and cooling requirements in the data center. On the desktop, an energy conscious user is also a realistic case, someone who lets the machine fully sleep at night but still wants a scheduled backup or sync job reliably executed.

5. Prerequisites: checking BIOS wake alarm and kernel support

For rtcwake to work reliably, the underlying hardware must support waking via an RTC alarm at all. On physical hardware this is mostly a matter of BIOS or UEFI, where a setting like "RTC Alarm" or "Wake on RTC" must be explicitly enabled, since some mainboards disable this feature by default to prevent accidental wakeups.

On the kernel side, you can check whether the RTC device is registered as a wakeup source via the file /sys/class/rtc/rtc0/device/power/wakeup, which contains either enabled or disabled. If the value is disabled, it can usually be set directly without a reboot. On virtual machines, support strongly depends on the hypervisor and must be tested separately if in doubt, since an emulated RTC does not necessarily provide the same wakeup features as physical hardware.

# Check if the RTC is registered as a wakeup source
cat /sys/class/rtc/rtc0/device/power/wakeup

# Enable it if it shows "disabled"
echo enabled | sudo tee /sys/class/rtc/rtc0/device/power/wakeup

# Check kernel log for wakeup related messages after a test cycle
dmesg | grep -i wakeup

6. Combining automation with systemd and scripts

For production use, rtcwake combines well with systemd, either via a timer that triggers a script which in turn programs a suspend followed by an alarm, or via an ExecStop hook that automatically sets the next wakeup time during a scheduled shutdown. It is important to cleanly separate the suspend call from the task to be executed, so that an error in the task does not leave the machine permanently stuck in an active state.

A robust pattern consists of three parts: a script that performs the actual task and logs its success, a second script that computes the next wakeup time after the task succeeds and calls rtcwake, and a systemd service unit that automatically kicks off this chain at system startup or after wakeup. That keeps the logic traceable and individually testable, rather than packing everything into a single, confusing script.

# /etc/systemd/system/nightly-backup-cycle.service
[Unit]
Description=Run backup, then suspend until next scheduled window

[Service]
Type=oneshot
ExecStart=/usr/local/bin/run-backup.sh
ExecStartPost=/usr/local/bin/schedule-next-wake.sh

7. Troubleshooting: why the machine does not wake up

The most common reason for a failed wakeup is a disabled wake alarm option in BIOS or UEFI, which ignores every RTC wakeup request regardless of the software configuration. The second common reason is a wrong timezone or a UTC/localtime misunderstanding in the hardware clock itself, causing the programmed alarm to trigger at a different time than intended, usually shifted by the local timezone offset.

A third reason is that some USB devices or peripherals affect the system's idle state and either prevent the scheduled suspend from happening at all or end it prematurely. Diagnosis always starts with a simple test run via rtcwake -m no to check whether the alarm is programmed correctly at all, followed by a short test interval with an actual suspend, before setting up a production, longer scheduled cycle.

8. Security aspects of automatic wakeup in server operation

A server that wakes itself up at scheduled times should first check whether the system time is correct after waking up, before time critical tasks start, since suspend cycles can in rare cases lead to delayed or faulty RTC synchronization. A short wait followed by checking the NTP synchronization status via chronyc tracking is a sensible safeguard here, before a backup or maintenance task actually begins.

In addition, an automatically waking server should never sit unprotected on the network while it is supposed to be asleep. Firewall rules and access controls must apply consistently regardless of the power saving state, so a brief wakeup window does not turn into an unattended time frame with reduced monitoring. Monitoring systems should be configured so that scheduled idle states are not falsely reported as an outage, while an unexpectedly long idle state still triggers an alert.

9. rtcwake, Wake-on-LAN, and cron solutions compared

There are several approaches to scheduled wakeup, which differ significantly in reliability and scope of use.

rtcwake and Wake-on-LAN can also be combined: rtcwake for regular, plannable cycles, Wake-on-LAN as an additional path for spontaneous, externally triggered wakeup outside the scheduled pattern. For pure scheduling without energy saving needs, a continuously running system with cron or systemd timers remains the simpler choice.

10. Summary

rtcwake actively puts a machine into a power saving state while simultaneously programming an alarm in the hardware clock that reliably reactivates the system at the scheduled time. The prerequisite is that both BIOS or UEFI and the kernel support waking via an RTC alarm, which can be checked via wakealarm and the power/wakeup file. Use cases range from nightly backup windows to energy conscious desktops to hardware test infrastructure that only needs to be active for scheduled test runs.

When automating the process with systemd, the actual task should be strictly separated from the suspend logic, so an error in the task does not leave the machine permanently in an active, unplanned state. After waking up, a brief check of the system time is worthwhile before time critical tasks start. Compared to Wake-on-LAN, rtcwake is especially suited for self-contained, recurring cycles without an external trigger.

11. FAQ: rtcwake and Scheduled Wakeups