~mil/sxmo-tickets#384: 
Still unreliable rtc wake with cronjobs

We made lot of work to wake the phone up before cronjob using mnc and sxmo_rtcwake.sh cronjob entrypoint.

But the fact is that we still miss jobs. By example, my wakeup alarm cronjob does not trigger ~1/3 :( Which is a big issue ! I still have to not suspend the whole night to have a reliable wake up alarm !

But I may have a solution: I'm playing with fcron at the moment.

Fcron is a scheduler. It aims at replacing Vixie Cron, so it implements most of its functionalities. But contrary to Vixie Cron, fcron does not need your system to be up 7 days a week, 24 hours a day : it also works well with systems which are running only occasionnally (contrary to anacrontab).

I got this fcron in my mind for some times cause I think it may be way more reliable on mobile phones. We actually use a lot of suspension moments.

I'm still learning my path with fcron. It allow powerfull things:

%daily 0-10 8 sxmo_rtcwake.sh echo foo bar

Which mean "one time per day between 08:00 and 08:10" (while the system is up)

Those special fcron % notation basically mean that if the phone wake up at 08:05, then the cronjob WILL TRIGGER.

There is some other options to indicate if the task should trigger after that moment if the system was off/suspended at this time.

I let you find all cool use cases but in short: with fcron, a sxmo user could then have very complex cronjobs that will works reliably.

So my point here is :

I think fcron is way more reliable to run on a mobile phone. It got lot of features a user could need in their device. If we make the choice to recommend it over cronie, we must adapt some minor things.

  • mnc does not real %daily entries

=> done

(We could also improve mnc to works with fcron notations)

  • the current sxmo_screenlock.sh hard code the usage of crontab -l which prevent the user to user other implementations

My best hope is to move the mnc computation (that trigger crontab -l) in a hook that the user can override. A simple sed script that convert fcron to cron is then enough to make mnc to works.

This could be sxmo_hooks.sh wakeupin which stdout X as a second delta.

=> done

Should we recommend fcron and adapt sxmo ? Should we just hardcode it usage (cause cronie just is unreliable in our context) ?

=> I think that using by default crontab is good enough. I add some help here for the user that was to use fcron

Status
REPORTED
Submitter
~stacyharper
Assigned to
No-one
Submitted
2 years ago
Updated
2 months ago
Labels
question

~stacyharper 2 years ago

This patch make it possible to overwrite the mnc behavior :

https://lists.sr.ht/~mil/sxmo-devel/patches/26128

~stacyharper 2 years ago

Here what I got as user "mnc" hook to handle fcron

#!/bin/sh 
 
fcrondyn -x "ls $(whoami)" \    | tail -n+2 \    | grep '|sxmo_rtcwake.sh' \    | cut -d'|' -f2- \    | sed 's/^[0-9]\+-\([0-9]\{2\}\)-\([0-9]\{2\}\)
\([0-9]\{2\}\):\([0-9]\{2\}\)|\(.*\)/\4 \3 \2 \1 * \5/' \    | mnc

The fcrondyn call will output:

ID   |SCHEDULE        |CMD
0    |2021-11-09 07:55|sxmo_rtcwake.sh sxmo_wm.sh execwait /mnt/sd/home/stacy/bin/red-hamster/wakeup

This simple sed will just convert this to a "cronjob" line. I then can use all fcron features and rely on its planned schedules to compute the next cron delay.

~stacyharper 2 years ago

With fcron, it behave very differently. It will keep in mind a delta between now and the next 08:00 (tomorrow by example). It will then decrease this delta every minute.

Example, we are 7:30 and we go to suspension and we wake up at 08:00; The task will trigger at 08:30 cause fcron still have to wait for 30 minutes.

This was a false.

In fact, fcron will detect it was suspended and reduce the delta accordingly.

But it looks like I still got a delay in some cases. Still dunno why o_O

~stacyharper 2 years ago

The fcrontab I'm using now

!bootrun,rebootreset
55 7 * * 1-5 sxmo_rtcwake.sh sxmo_wm.sh execwait /mnt/sd/home/stacy/bin/red-hamster/wakeup
!reset

!bootrun mean that the job will trigger if the system was off or suspended while the job was expected to trigger

!rebootreset mean that the next job scheduled is recomputed on system reboot

I use both to make the cronjob reliable with suspension while not triggering the alarm if the phone was off at the alarm trigger datetime (not trigger alarm on reboot).

~stacyharper 2 years ago*

But fcron jobs still sometime are delayed of 20~30 mn

So I'm actually using this to wake up to 8:00 am

!bootrun,rebootreset
<a href="/~mil/sxmo-tickets/20" title="~mil/sxmo-tickets#20: sxmo-utils: Warning for missing modem">#20</a> 23 * * * sxmo_rtcwake.sh sxmo_wm.sh execwait /mnt/sd/home/stacy/bin/red-hamster/wakeup
30 7 * * 1-5 sxmo_rtcwake.sh sxmo_wm.sh execwait /mnt/sd/home/stacy/bin/red-hamster/wakeup
40 7 * * 1-5 sxmo_rtcwake.sh sxmo_wm.sh execwait /mnt/sd/home/stacy/bin/red-hamster/wakeup
!reset

~phartman 1 year, 5 months ago*

Small update, since I went down a debugging rabbithole:

o Problem has nothing to do with sxmo_mutex.sh locks.

o Not a race condition between cronjobs (only one cronjob).

o One proposal (which does fix it for me):

  • in sxmo_hook_mnc.sh bump the time from 10 to 70 to give crond enough time to poll after waking from suspend.
  • in sxmo_hook_postwake.sh add an [ "$UNSUSPENDREASON" = "rtc" ] && sudo /etc/initi.d/crond restart (maybe not necessary but at least gives crond that nudge when waking from reason)

I had both of these for about a year now and everything was working great. I recently reverted back to the default mnc and I saw the bug again.

o Long term solution? Write our own scheduler!

~phartman REPORTED WONT_FIX 1 year, 2 months ago

~stacyharper WONT_FIX REPORTED 1 year, 2 months ago

I woul prefer to keep this one open. We could implement our own cronjob scheduler

~stacyharper 2 months ago

For the first times ever, I got a working cronjob scheduler. I did what I said, I implemented a better one:

https://git.sr.ht/~stacyharper/mcron

Still WIP, mainly because it depends on non upstream yet stdlib patches.

Register here or Log in to comment, or comment via email.