Desktop alarm scheduling may not survive the machine sleeping (no OS wake-timer integration)

[ScottMorris]

Context

Came up while discussing the Android permission-diagnostic work in #282/#284: those four checks (full-screen intent, exact-alarm scheduling, battery-optimization exemption, notifications) are all Android-specific and correctly no-op on desktop (plugins/alarm-manager/src/desktop.rs, plugins/os-prefs/src/desktop.rs -- check_* always return Ok(true), open_* are no-ops, and the frontend gates the whole diagnostic behind isAndroid in Settings.tsx so these never even get called there). None of that needed a desktop equivalent -- but looking at the actual desktop scheduler while answering "does macOS/Windows need something similar" surfaced a different, unrelated gap worth tracking.

What was found

AlarmManager::schedule_internal (plugins/alarm-manager/src/desktop.rs) is a plain tokio::spawn task that computes a delay and calls sleep_until. There's no integration with either platform's OS-level wake-from-sleep mechanism:

• Windows: SetWaitableTimerEx with the WAKE_SYSTEM flag (or the Task Scheduler equivalent) is the sanctioned way to have the OS actually wake a sleeping machine at a specific time.
• macOS: power-assertion APIs (IOPMAssertionCreateWithName / pmset-adjacent mechanisms) are the equivalent.

Without either, it's unclear what actually happens if the desktop/laptop is asleep when a scheduled alarm's trigger time arrives -- does it fire late on wake, or not until something else wakes the machine? This hasn't been tested; sleep_until's behaviour across an OS suspend/resume cycle wasn't verified as part of this investigation, just flagged as untested.

Why it matters

For a phone, this is a non-issue -- AlarmManager.setAlarmClock (Android) already guarantees a Doze-mode wake. For desktop, if Threshold is meant to be a serious "this will wake you up" surface rather than just a convenience mirror of the phone app, a laptop that's asleep at 7am with the lid closed is exactly the scenario that needs to work.

Suggested next step

1. Verify actual behaviour empirically on both platforms: schedule an alarm, put the machine to sleep, and observe what happens at/after the trigger time.
2. If it doesn't fire reliably, look at wiring up the platform-specific wake-timer APIs above from desktop.rs's scheduler.

Not scoped or estimated -- this is a "worth investigating" flag, not a confirmed bug report.

Reference

Discussed while working on #282/#284: #282

[ScottMorris]

Research: what actually happens, per platform

Confirmed this app ships desktop bundles for all three platforms (tauri.conf.json's bundle.targets is "all", plus an explicit windows config section), so this isn't just a Linux-dev-environment curiosity -- it's a real gap on every desktop target Threshold distributes for.

The root cause: std::time::Instant (which tokio::time::sleep_until is built on) is suspend-unaware on Linux and macOS, but suspend-aware on Windows

Platform	Clock source behind Instant::now()	Ticks during suspend?
Linux	CLOCK_MONOTONIC	No
macOS	Apple's continuous/uptime clock (not CLOCK_UPTIME_RAW)	No
Windows	QueryPerformanceCounter (suspend-aware since Rust 1.77)	Yes

This means the failure mode is actually different per platform, not just "doesn't fire":

• Linux/macOS: the timer effectively pauses for the duration of the sleep (since the elapsed-Instant math doesn't count suspended time), then resumes counting down the remaining, not-yet-elapsed duration once the machine wakes for any reason. Net effect: the alarm fires late by roughly however long the machine was asleep, on top of whatever incidental event actually woke it.
• Windows: Instant's internal deadline math is wall-clock-correct through the sleep, but the process itself isn't executing while suspended, so the callback still can't run until something else wakes the machine -- at which point it fires essentially immediately (the "logical" deadline already passed). So Windows doesn't add the extra post-wake delay Linux/macOS do, but it's equally dependent on an unrelated event waking the machine in the first place.

There was a real proposal to make Linux's Instant suspend-aware by switching to CLOCK_BOOTTIME (rust-lang/rust#88714), but it was closed without merging in Dec 2022 -- the libs team's reasoning was that Linux syscalls like futex/pthread_cond_t only support CLOCK_REALTIME/CLOCK_MONOTONIC, so switching just one platform without cross-platform guarantees wasn't judged worth the inconsistency with macOS. The boot-time crate exists specifically to paper over this (suspend-aware Instant via CLOCK_BOOTTIME on Linux), and Rippling's suspend-time crate exists for the inverse (forcing suspend-unaware behaviour consistently cross-platform) -- confirming this is a known, currently-unsolved gap in std, not something specific to how this app's code is written.

None of the three platforms will wake a sleeping machine without explicit opt-in -- and the opt-in mechanism differs a lot in how reachable it is from ordinary app code

• Windows: SetWaitableTimerEx with fResume = TRUE (the WAKE_SYSTEM behaviour) is the sanctioned API, callable from ordinary user-mode code with no elevation. Caveat: it's only effective if "Allow wake timers" is enabled in the active power plan -- a user-configurable setting that can be off by default on some machines/power plans, so the API can succeed while still not actually waking anything.
• macOS: IOPMSchedulePowerEvent (IOKit) is the equivalent. I could not confirm from research whether this is callable from an ordinary (non-privileged, non-daemon) GUI app without a special entitlement or root -- this needs hands-on verification against a real signed build rather than more searching, flagging as an open question rather than asserting either way.
• Linux: meaningfully harder. The traditional mechanism is the RTC wake alarm (/sys/class/rtc/rtc0/wakealarm, or the rtcwake utility that wraps it) -- and every source found says this requires root. systemd timer units support WakeSystem=true, but that's a mechanism for systemd-managed timer units, not something an ordinary running GUI process can trivially invoke for itself without shelling out to systemctl/loginctl and hitting whatever polkit policy is configured on that distro. This is likely the least portable of the three.

Bottom line

• The "does it fire late or not at all" question now has a concrete, sourced answer: late, by roughly the sleep duration (worse on Linux/macOS than Windows), provided something else wakes the machine at all -- none of the three platforms will wake a fully suspended machine on their own without extra, platform-specific, unevenly-privileged integration work.
• Still not empirically tested against a real build on any of the three platforms -- this is desk research explaining why the suspicion in the issue description is well-founded, not a substitute for the "put a laptop to sleep with a pending alarm and watch what happens" step already listed above.
• Given Linux's RTC path needs root and macOS's entitlement story is unconfirmed, a full fix here is likely more involved than "call one API from desktop.rs" -- worth scoping degree of effort once/if this gets picked up, rather than assuming a small change.

Sources: Suspend-Unaware Cross-Platform Monotonic Time in Rust (Rippling), rust-lang/rust#87906, rust-lang/rust#79462, rust-lang/rust#88714, boot-time crate docs, suspend-time crate, tokio-rs/tokio#4714, Microsoft: System Wake-up Events, Enable/Disable Wake Timers (Windows), IOPMSchedulePowerEvent docs, rtcwake(8) man page

[ScottMorris]

Follow-up research: Linux desktop-environment / XDG integration

Asked separately: is there a DE-level or XDG-standard API for this on Linux, rather than raw RTC access? Findings refine (and partly correct) the Linux section of the previous comment.

No XDG portal exists yet -- it's an open proposal, not a shipped standard

There's an active discussion, flatpak/xdg-desktop-portal#1377 ("Alarm Portal"), and a related issue, #1025 ("Alarms: Explicit Addition and Notification"), proposing exactly this -- a portal so sandboxed (Flatpak) apps could schedule alarms including a wake mechanism. As of this research it's still in discussion/proposal form, not a finalized or implemented portal. So: no, there's nothing to integrate against today at the XDG level.

Telling data point: GNOME's own built-in alarm app doesn't reliably solve this either

GNOME Clocks has an open, unresolved feature request titled "Don't suspend while timer is running" -- meaning the reference alarm app for the GNOME desktop doesn't currently guarantee this works either. There's a dedicated systemd issue tracking it: systemd/systemd#21382 ("rtcwake for gnome-clock"). This is a useful sanity check: it's not that Threshold is missing something every other Linux alarm app has solved -- this is a genuinely open, ecosystem-wide gap.

Correction/refinement: it's not "root" specifically, it's the CAP_WAKE_ALARM Linux capability

My earlier comment said the RTC wakealarm path "requires root" -- more precisely, the real kernel-level mechanism is timerfd_create(CLOCK_BOOTTIME_ALARM, ...) (or CLOCK_REALTIME_ALARM), which is gated by the CAP_WAKE_ALARM POSIX capability specifically, not full root. That capability can be granted narrowly to just the app's binary via setcap 'cap_wake_alarm=ep' /path/to/binary, without running the whole process as root. This is confirmed as the actual blocker for gnome-clocks: "a non-privileged user isn't allowed to create a timer with timerfd_create that can wake up the system from suspend, because they don't have access to CLOCK_BOOTTIME_ALARM/CLOCK_REALTIME_ALARM" without it. Relatedly, systemd/systemd#17564 tracks making WakeSystem= available to user systemd timer units (currently system-manager/root-only) -- same underlying capability gap, different angle.

KDE's KAlarm ships this today, for reference -- via user-consented elevation, not silent root

KAlarm implements "wake from suspend" using rtcwake -t <time>, run through KAuth (KDE's privilege-escalation framework) -- so in practice it's an explicit, user-consented polkit/authentication prompt (once, or cached), not something running silently as root. Real-world texture: there was a shipped bug where the KAuth helper process exited before rtcwake finished, breaking the feature (fixed in KAlarm 3.9.2) -- a useful signal that even the one production implementation of this found is fiddly in practice.

The more practical starting point: prevent sleep rather than wake from it

systemd-logind's Inhibit() D-Bus API (org.freedesktop.login1.Manager) is the standard, portable, no-special-capability-required mechanism across GNOME/KDE/every systemd-based desktop: an app takes a sleep inhibitor lock (mode block or delay) to stop the machine from suspending in the first place. This can't rescue a machine that's already asleep with no lock held (e.g. user manually closed the lid with no alarm imminent yet), but it's a meaningfully lower-effort, no-elevation, cross-DE mechanism Threshold could take out proactively when an alarm's trigger time is approaching -- closer in spirit to "don't let the machine sleep through this" than "wake it up after the fact." Worth treating as a distinct, smaller-scoped option from the RTC/CAP_WAKE_ALARM wake-after-the-fact approach, not a replacement for it (they solve different halves of the problem: inhibit handles "still awake, about to sleep"; wake-alarm handles "already asleep before the app knew to inhibit").

Sources: Alarm Portal discussion, xdg-desktop-portal#1025, [gnome-clocks "don't suspend while timer running" / CAP_WAKE_ALARM search results], systemd/systemd#21382, systemd/systemd#17564, Bytezz/alarm (GNOME alarm app using systemd WakeSystem), KAlarm, KDE bug 486187 (rtc wakeup), systemd Inhibitor Locks, freedesktop.org inhibit wiki, rtcwake(8)