rtcwake und geplantes Aufwachen: Server und Desktops zur richtigen Zeit reaktivieren

1. Wofuer rtcwake gedacht ist: Power-Management trifft Scheduling

Klassisches Scheduling mit Cron oder systemd-Timern setzt voraus, dass der Rechner durchgehend eingeschaltet ist. Fuer viele Anwendungsfaelle ist das unnoetig: Ein Home-Server, der nur nachts ein Backup erstellen soll, ein Testrack, das nur fuer geplante Testlaeufe aktiv sein muss, oder ein energiebewusster Desktop, der zwischen Nutzungszeiten nicht durchlaufen soll, profitieren davon, den Grossteil der Zeit im Ruhezustand zu verbringen. Genau hier setzt rtcwake an, indem es Suspend-Zustaende mit einem exakt geplanten Aufwachzeitpunkt kombiniert.

Der grundlegende Gedanke: Statt eines durchlaufenden Systems, das per Timer eine Aufgabe ausloest, versetzt rtcwake den Rechner aktiv in einen Energiesparzustand und programmiert gleichzeitig einen Alarm in der Hardware-Uhr, der das System zuverlaessig wieder aufweckt, auch wenn der Prozessor waehrend des Ruhezustands keine Instruktionen mehr ausfuehrt. Das reduziert Stromverbrauch und Verschleiss erheblich, ohne auf geplante Aufgaben verzichten zu muessen.

2. Wie rtcwake funktioniert: RTC-Alarm und ACPI-Wakeup

Technisch nutzt rtcwake eine Funktion, die viele RTC-Chips zusaetzlich zur reinen Zeitmessung bieten: einen programmierbaren Alarm, der zu einem festgelegten Zeitpunkt ein Interrupt-Signal ausloest. Dieses Signal wird vom ACPI-Subsystem des Kernels abgefangen und je nach Energiesparzustand genutzt, um das System aus Suspend to RAM, Suspend to Disk oder einem anderen Ruhezustand aufzuwecken, unabhaengig davon, ob der Prozessor selbst noch aktiv ist.

Der Ablauf ist dabei zweigeteilt: Zuerst schreibt rtcwake den gewuenschten Aufwachzeitpunkt in das wakealarm-Attribut der RTC unter /sys/class/rtc/rtc0/wakealarm, danach initiiert es den eigentlichen Uebergang in den gewuenschten Energiesparzustand. Sobald die RTC den programmierten Zeitpunkt erreicht, generiert sie ein Wakeup-Event, das die Hardware ueber ACPI zurueck in einen aktiven Zustand versetzt, woraufhin der Kernel den normalen Boot- beziehungsweise Resume-Vorgang fortsetzt.

# 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. Grundlegende Nutzung: Modi, Zeitangaben und Optionen

Der Befehl rtcwake kennt mehrere Suspend-Modi ueber die Option -m. mem steht fuer Suspend to RAM, den energiesparendsten Zustand mit schnellem Aufwachen, disk fuer Hibernation, bei der der Zustand vollstaendig auf die Festplatte geschrieben wird und der Rechner danach komplett stromlos bleiben kann. Die Option no programmiert nur den Alarm, ohne tatsaechlich einen Suspend-Zustand einzuleiten, was fuer Tests und Diagnosen sehr nuetzlich ist.

Die Zielzeit laesst sich entweder relativ ueber -s Sekunden oder absolut ueber -t Unix-Zeitstempel angeben. Fuer die Praxis ist die relative Angabe meist intuitiver, waehrend die absolute Angabe sich besser fuer generierte Skripte eignet, die eine feste Zieluhrzeit berechnen. Die Option --verbose gibt zusaetzlich detaillierte Informationen ueber die berechnete Aufwachzeit und den gewaehlten Modus aus, was besonders bei der ersten Einrichtung fuer Diagnosezwecke wertvoll ist.

# 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. Anwendungsfaelle: Backup-Fenster, Energiesparen, Testracks

Der klassische Anwendungsfall ist ein Home-Server oder kleiner Buero-Server, der ausserhalb der Buerozeiten im Ruhezustand bleibt und nur fuer ein nachtliches Backup-Fenster aufwacht. Ein Skript versetzt den Server nach Feierabend in den Suspend-Zustand mit einem programmierten Alarm fuer die Backup-Zeit, das Backup laeuft, und anschliessend geht der Server automatisch wieder in den Ruhezustand, bis am naechsten Morgen der reguläre Betrieb beginnt.

Ein zweiter haeufiger Fall ist Hardware-Testinfrastruktur, bei der viele physische Testracks nur fuer geplante, automatisierte Testlaeufe aktiv sein muessen. Statt Dutzende Maschinen durchlaufen zu lassen, weckt ein zentraler Scheduler jede Maschine kurz vor ihrem geplanten Testlauf per rtcwake auf, was Energiekosten und Kuehlungsbedarf im Rechenzentrum spuerbar senkt. Auch auf dem Desktop ist ein energiebewusster Nutzer ein realistischer Fall, der den Rechner nachts komplett schlafen legt, aber ein geplantes Backup oder einen Sync-Job trotzdem zuverlaessig ausgefuehrt haben moechte.

5. Voraussetzungen: BIOS-Wake-Alarm und Kernel-Support pruefen

Damit rtcwake zuverlaessig funktioniert, muss die zugrunde liegende Hardware das Aufwecken per RTC-Alarm ueberhaupt unterstuetzen. Bei physischer Hardware ist das meist eine Frage des BIOS oder UEFI, wo eine Einstellung wie "RTC Alarm" oder "Wake on RTC" explizit aktiviert sein muss, da manche Mainboards diese Funktion standardmaessig deaktivieren, um versehentliches Aufwachen zu verhindern.

Auf Kernel-Seite laesst sich pruefen, ob das RTC-Geraet als Wakeup-Quelle registriert ist, ueber die Datei /sys/class/rtc/rtc0/device/power/wakeup, die entweder enabled oder disabled enthaelt. Ist der Wert disabled, laesst er sich meist direkt setzen, ohne dass ein Neustart noetig ist. Bei virtuellen Maschinen ist die Unterstuetzung stark vom Hypervisor abhaengig und muss im Zweifel getrennt getestet werden, da eine emulierte RTC nicht zwingend dieselben Wakeup-Funktionen wie physische Hardware bereitstellt.

# 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. Automatisierung mit systemd und Skripten kombinieren

Fuer den produktiven Einsatz laesst sich rtcwake gut mit systemd kombinieren, entweder ueber einen Timer, der ein Skript ausloest, das seinerseits einen Suspend mit anschliessendem Alarm programmiert, oder ueber einen ExecStop-Hook, der beim geplanten Herunterfahren automatisch den naechsten Aufwachzeitpunkt setzt. Wichtig ist dabei, den Suspend-Aufruf und die auszufuehrende Aufgabe sauber voneinander zu trennen, damit ein Fehler in der Aufgabe nicht dazu fuehrt, dass der Rechner dauerhaft im aktiven Zustand haengen bleibt.

Ein robustes Muster besteht aus drei Teilen: einem Skript, das die eigentliche Aufgabe ausfuehrt und deren Erfolg protokolliert, einem zweiten Skript, das nach erfolgreicher Aufgabe den naechsten Aufwachzeitpunkt berechnet und rtcwake aufruft, und einer systemd-Service-Unit, die diese Kette beim Systemstart oder nach dem Aufwachen automatisch anstoesst. So bleibt die Logik nachvollziehbar und einzeln testbar, statt alles in ein einziges, unuebersichtliches Skript zu packen.

# /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: Warum der Rechner nicht aufwacht

Der haeufigste Grund fuer ein fehlgeschlagenes Aufwachen ist eine deaktivierte Wake-Alarm-Option im BIOS oder UEFI, die unabhaengig von der Software-Konfiguration jede RTC-Aufwachanfrage ignoriert. Der zweite haeufige Grund ist eine falsche Zeitzone oder ein UTC/Localtime-Missverstaendnis in der Hardware-Uhr selbst, wodurch der programmierte Alarm zu einem anderen als dem beabsichtigten Zeitpunkt ausgeloest wird, meist um die Differenz der lokalen Zeitzone verschoben.

Ein dritter Grund ist, dass manche USB-Geraete oder Peripherie den Ruhezustand des Systems beeinflussen und den geplanten Suspend gar nicht erst zulassen oder ihn vorzeitig beenden. Die Diagnose beginnt immer mit einem einfachen Testlauf ueber rtcwake -m no, um zu pruefen, ob der Alarm ueberhaupt korrekt programmiert wird, gefolgt von einem kurzen Testintervall mit echtem Suspend, bevor ein produktiver, laenger geplanter Zyklus eingerichtet wird.

8. Sicherheitsaspekte bei automatischem Aufwachen im Serverbetrieb

Ein Server, der sich selbststaendig zu geplanten Zeiten aufweckt, sollte nach dem Wiederaufwachen zunaechst pruefen, ob die Systemzeit korrekt ist, bevor zeitkritische Aufgaben starten, da Suspend-Zyklen in seltenen Faellen zu einer verzoegerten oder fehlerhaften RTC-Synchronisation fuehren koennen. Eine kurze Wartezeit mit anschliessender Pruefung des NTP-Synchronisationsstatus ueber chronyc tracking ist hier eine sinnvolle Absicherung, bevor eine Backup- oder Wartungsaufgabe tatsaechlich beginnt.

Zusaetzlich sollte ein automatisch aufwachender Server niemals ungeschuetzt im Netzwerk haengen, waehrend er eigentlich schlafen sollte. Firewall-Regeln und Zugriffskontrollen muessen unabhaengig vom Energiesparzustand konsistent greifen, damit ein kurzes Aufwachfenster nicht zu einem unbeaufsichtigten Zeitfenster mit reduzierter Ueberwachung wird. Monitoring-Systeme sollten so konfiguriert sein, dass geplante Ruhezustaende nicht faelschlich als Ausfall gemeldet werden, aber ein unerwartet langer Ruhezustand trotzdem einen Alarm ausloest.

9. rtcwake, Wake-on-LAN und Cron-Loesungen im Vergleich

Fuer geplantes Aufwachen gibt es mehrere Ansaetze, die sich in Zuverlaessigkeit und Einsatzbereich deutlich unterscheiden.

rtcwake und Wake-on-LAN lassen sich zudem kombinieren: rtcwake fuer regelmaessige, planbare Zyklen, Wake-on-LAN als zusaetzlicher Weg fuer spontanes, extern ausgeloestes Aufwecken ausserhalb des geplanten Musters. Fuer reine Zeitplanung ohne Energiesparbedarf bleibt ein durchlaufendes System mit Cron oder systemd-Timern weiterhin die einfachere Wahl.

10. Zusammenfassung

rtcwake versetzt einen Rechner aktiv in einen Energiesparzustand und programmiert gleichzeitig einen Alarm in der Hardware-Uhr, der das System zuverlaessig zum geplanten Zeitpunkt reaktiviert. Voraussetzung ist, dass sowohl BIOS oder UEFI als auch der Kernel das Aufwecken per RTC-Alarm unterstuetzen, was sich ueber wakealarm und die power/wakeup-Datei pruefen laesst. Anwendungsfaelle reichen von nachtaktiven Backup-Fenstern ueber energiebewusste Desktops bis zu Hardware-Testinfrastruktur, die nur fuer geplante Testlaeufe aktiv sein muss.

Automatisiert man den Ablauf mit systemd, sollte die eigentliche Aufgabe strikt von der Suspend-Logik getrennt werden, damit ein Fehler in der Aufgabe nicht zu einem dauerhaft aktiven, ungeplanten Zustand fuehrt. Nach dem Aufwachen ist eine kurze Pruefung der Systemzeit sinnvoll, bevor zeitkritische Aufgaben starten. Im Vergleich zu Wake-on-LAN eignet sich rtcwake besonders fuer selbststaendige, wiederkehrende Zyklen ohne externen Trigger.

11. FAQ: rtcwake und geplantes Aufwachen