Schedule a Safe Linux Wake-Up with rtcwake

A backup job that starts before the machine wakes up is no job at all, and rtcwake puts a Linux box to sleep while guaranteeing it comes back. You will schedule a wake after a known interval, choose the sleep state deliberately, and check the hardware clock setting first. Allow 10 to 15 minutes for a first test, plus access to the machine's console or a way to observe it returning from sleep.

This guide describes the installed command and manual pages checked here: the rtcwake binary reports util-linux 2.42.4, while the installed manpages are from util-linux 2.39.3. The core options used below are present in both. Sleep and RTC support still depend on the kernel, firmware and hardware.

1. Check the command and available sleep modes

Run these as your ordinary user first. They do not schedule an alarm or suspend the machine:

$ command -v rtcwake
/home/linuxbrew/.linuxbrew/sbin/rtcwake
$ rtcwake --version
rtcwake from util-linux 2.42.4
$ rtcwake --list-modes
freeze mem disk off no on disable show

• freeze freezes processes and suspends devices.
• mem is suspend-to-RAM.
• disk is suspend-to-disk.

The default is standby according to the 2.39.3 manual, but this binary's mode list is the authority for this installation, so select a mode explicitly rather than trust the default.

2. Check how the RTC is interpreted

By default, rtcwake uses --auto and reads the clock mode from /etc/adjtime. The file's third line is normally either UTC or LOCAL. If the file is missing, the adjtime manual says the default clock mode is UTC.

$ sudo sh -c 'test -r /etc/adjtime && sed -n "1,3p" /etc/adjtime || echo "/etc/adjtime is absent or unreadable"'
0.000000 0 0
0
UTC

Your drift and timestamp values will differ; the third line is the part that matters here. Do not edit /etc/adjtime casually: it is maintained by hwclock and also records drift information. If you know the hardware clock is UTC, make that choice explicit with --utc. If it is local time, use --local. An alternative file can be selected with --adjfile PATH.

3. Perform a no-sleep rehearsal

Use --dry-run while checking syntax and the selected mode. It performs the setup work apart from actually setting the alarm, suspending the system or waiting for the alarm. It may still need permission to access the RTC device, so run it with sudo if an ordinary-user test reports permission denied.

$ sudo rtcwake --dry-run --utc --mode mem --seconds 900

The command should return to the shell without putting the machine to sleep. A message such as /dev/rtc0: unable to find device: Permission denied means the rehearsal could not inspect the RTC with the current permissions; it is not evidence that a real suspend will work. Check the device and kernel messages before proceeding:

$ ls -l /dev/rtc*
$ dmesg | tail -n 30

Use elevated access only for the checks that need it. Do not make a normal user session permanently privileged just to run a wake-up command.

4. Schedule a relative wake-up

Once the rehearsal and hardware checks are satisfactory, --seconds expresses the wake-up interval from now. This example requests suspend-to-RAM for 15 minutes:

$ sudo rtcwake --utc --mode mem --seconds 900

For the first real test, use a short interval while you are physically near the machine. If the command fails before sleep, preserve the error text and check the RTC device, firmware settings and supported kernel sleep states. If it sleeps but does not resume, use the machine's power controls and firmware documentation rather than repeatedly retrying long intervals.

5. Use a calendar time when the deadline matters

Use --date for a human-readable wake-up time. The manual accepts forms such as YYYY-MM-DD hh:mm, hh:mm, tomorrow and relative text such as +5min. Quote values containing spaces:

$ sudo rtcwake --utc --mode mem --date '2026-09-27 07:30'

With a time-only value, the date is today. With a date-only value, the time is midnight. Check the date and timezone before using either form near midnight or around a daylight-saving change. If you need an absolute Unix timestamp, use --time with seconds since 1970-01-01 00:00 UTC:

$ date --date '2026-09-27 07:30 UTC' +%s
1790494200
$ sudo rtcwake --utc --mode mem --time 1790494200

6. Disable an alarm or inspect its state

If you set an alarm but decide not to suspend, disable that alarm explicitly:

$ sudo rtcwake --utc --mode disable

To inspect the RTC alarm without suspending, use the show mode:

$ sudo rtcwake --utc --mode show
alarm: on Sun Sep 27 07:30:00 2026

The exact date and wording depend on the RTC and the installed version. --mode no also avoids suspending, but it still sets the wake-up alarm, so it is not a harmless inspection mode. --mode on waits for an alarm and is described by the manual as a debugging mode; do not use it on a machine that must stay responsive without understanding that wait.

Common traps

• The time is wrong: check whether the RTC is UTC or local time, then use exactly one of --auto, --utc or --local. Do not mix a local clock assumption with a UTC timestamp without converting it first.
• The mode is rejected: compare the request with rtcwake --list-modes. The available modes are not identical across every kernel and platform.
• The RTC cannot be opened: inspect /dev/rtc0, try the correct device with --device rtc1 if the machine has more than one RTC, and check permissions. The default device is rtc0.
• The system wakes late or not at all: hardware alarm limits, firmware and active devices can interfere. The manual specifically warns that not every RTC can set an alarm more than 24 hours ahead.