Hacker News Reader

Comment by julienpalard | Hacker News Reader

True. There's a demo prooving it: https://wiki.mobian-project.org/doku.php?id=wake-mobile

(Tested on my PinePhone on Mobian: it works!)

Yep, all the alarm clock program really needs to do for this to work, is to setup a timerfd with CLOCK_REALTIME_ALARM flag set.

Then timer firing will wake the system.

That's pretty much it. Standard Linux feature across all systems that support system suspend and RTC wakeup.

man timerfd_create

And for non-systemd systems like postmarketOS, there's waked that writes directly to the RTC dev node directly for the same effect. pmos also patches gnome-clocks to use waked.

That's an "interesting" solution, since exactly what waked does is already done by kernel internally if you use timerfd, without the need for any special daemon. Any app that wants to be woken up at certain time can just register a timer for that time with the kernel.

I wonder if waked writing directly to RTC doesn't break the kernel alarm functionality used by timerfd, but hopefully not https://gitlab.com/seath1/waked/-/blob/master/src/main.cpp#L...

But why not, it's FOSS. :)

The issue is that it's not possible to create wakeup timers without root or CAP_WAKE_ALARM, hence why you need a more privileged daemon of some sort that your regular alarm clock app binary. Eg with systemd it doesn't let timer units in the user session that can wake the system, which is what is blocking gnome-clocks upstream from using systemd timer units.

But yes, I don't know why waked uses the dev node directly instead of using CLOCK_ALARM, and it's definitely possible it interferes with anything else going through the kernel using CLOCK_ALARM.

Maybe I'm missing something, but why not simply `setcap cap_wake_alarm+p gnome-clocks` and any other app that may legitimately use this?

No, you're not missing anything. I should've been clearer that I was talking about gnome-clocks specifically, which wants to use systemd both so that only systemd needs the privileges rather than gnome-clocks itself and so that it can autostart gnome-clocks using the timer [1] even if gnome-clocks is down at the time (ie gnome-clocks doesn't itself need to keep the timerfd alive).

In general, setcap'ing the binary will work fine.

[1]: https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests...

I think one reason not to use the timerfd method is that you (waked) could drop the fd if it terminates unexpectedly. There is probably a way to persist the db separately... But the device node is right there.

If waked terminates unexpectedly, it has to be told about all the registered alarms by all apps again after restarting. Apps need to be notified to provide the info again, etc. If waked would keep a database, then you have a syncing problem, between apps and waked, possibility of desynchronization. If app crashes, and doesn't remove alarms from waked, the phone will wakeup, but there will be no app to present the UI. Sounds confusing.

Automatic resource management by kernel when the app crashes or is stopped is actually quite nice. You just restart the app and setup the timers again from the stored settings. You have to store alarms persistently, in any case. You'll get event in the eventloop of the app that registered the timer, etc. Complexity of the solution is minimal. Less opportunity for bugs and failures.

it has to be told about all the registered alarms by all apps again after restarting

Is that true? Or does it just read from the rtc state? (Or leave it alone?) Also for efficiency reasons, don't you want a single wakeup being scheduled rather than potentially spaced out wakeups?

stored settings

Aka a database, right? Albeit a per-user database. What you are talking about sounds more like a service (daemon) than an app, though, from my perspective. A sort of per-user waked. That operates by holding timerfds it negotiated away from a privileged service. You can't revoke FDs anymore/yet, right? Although you can mark them cloexec and go on a killing spree.

> Is that true?

Yes.

I just want the timer to fire and be handled in the process where it's needed, regardless if the system is suspended or not completely transparently. Waked doesn't help with that. I certainly don't want a special daemon that I have to register with over a complicated protocol (d-bus) in addition to having to manage the timers in app when it can be avoided just by passing a single flag to timerfd_create which will work universally and will not depend on systemd.

Spliting alarms into a deamon and UI shell is kinda pointless unless some other app would need access to alarms. But that would be a different service than waked in any case. Waked doesn't handle timers.

Reply on news.ycombinator.com