Cronjob on sailfish?
Any way to create a cronjob on Sailfish?
We have moved to a new Sailfish OS Forum. Please start new discussions there.
Any way to create a cronjob on Sailfish?
As a follow-up to a previous hint, here's a short description on how to easily setup recurring tasks with systemd. The systemd timer is the closest approach to a cron-like functionality while staying with the native system facilities.
To schedule a script with tasks that are recurring in an e.g. weekly manner, a corresponding timer file has to be created. There are two types of specifying timers, monotonic ones (relative to system boot) or realtime ones (well, related to the realtime clock). Traditional cron is using the realtime clock, so I'm going to stick with this.
weekly.timer
[Unit]
Description=Run weekly script
[Timer]
OnCalendar=weekly
Persistent=true
[Install]
WantedBy=timers.target
Apart from the file that hooks into the timer, a related service file must be present:
weekly.service
[Unit]
Description=Run weekly script
[Service]
ExecStart=/home/nemo/sdcard/admin/weekly
Now put both files into /etc/systemd/system and enable the timer file via
sudo systemctl enable weekly.timer
EDIT: /home/nemo/sdcard/admin/weekly is of course a shell script with all tasks to be executed in a weekly manner.
I prefer the systemd solution, however what about the issue with failing to trigger on time when the phone goes to sleep? https://together.jolla.com/question/56581/systemdtimer-not-fireing-when-time-elapses-and-phone-in-deep-sleep-use-timedclient-qt5-instead/
Robin ( 2015-02-07 06:48:03 +0200 )editanswered 2014-05-21 17:30:21 +0200
Until a real cron is available, there is a way to create scheduled, repeating tasks not quite unlike cron jobs, using timed. The same thing that powers you alarm clock; it can be configured to run arbitrary commands (a bash script would be a sane choice). To set up say hourly, daily, weekly and monthly runs is relatively straightforward.
I tested the approach for my automated backup system and it seems to be working fine so far. To set up a daily job to run at midnight would require something like this:
$ timedclient-qt5
-a'whenDue;runCommand=YOUR_COMMAND_HERE@nemo'
-r'hour=0;minute=0;everyDayOfWeek;everyDayOfMonth;everyMonth'
-e'APPLICATION=YOUR_APPLICATION_NAME_HERE;TITLE=YOUR_TASK_NAME_HERE'
I'm not really sure what is the exact meaning of 'whenDue', but it seems to do the job. The run-as-user part of runCommand (@nemo) could of course be something else, too. Pay attention to the order of the parameters, there are requirements to it (read timedclient-qt5 --help
).
This feels like a bit dirty solution, but in the absence of cron, I guess there are no other options.
EDIT: Sorry for the lousy line wrap, I don't know why it's wrapped in between - and the parameter letter...
@holist: curious about your backup system. I am about to write a little shell script (or maybe even python) to be triggered with the timedclient-qt5. I will use rsync with ssh, but I have no idea how to check the bearer-type (I want to backup only if I am connected to the wlan). That can be done from a qt application I've read, but can it be done from a script? Maybe some dbus thingy? Have you got any idea?
Larswad ( 2014-05-27 15:05:34 +0200 )edit@Larswad: check for "up" in /sys/class/net/wlan0/operstate
.
Cron works pretty nice on sailfsh. The trick is to use DSME/iphb socket interface to get the reliable wakeup tick.
I have now run the basic sailfish port of cron-for-harmattan (https://gitorious.org/cron-for-harmattan) for a few weeks, and it is very stable; on my tests for a week it never missed a wakeup, however deep-sleeping the device was. It does not add too much of battery consumption, most of the time crond is sleeping on the socket waiting for the next event to occur. Yesterday, for example I removed charger at 06:00, ran the day with light tasks; some phonecalls, a little surfing on TMO, a little playing Heebo, wrote 2 emails, sent few SMS'es, no navigation that day (but location services enabled) When I went to sleep 19 hours later, the device still had 77% charge left.
My main use for cron is to trigger my email refresh; I have a fairly complicated requirements for that, impossible to implement with the email sync interface:
OK, so finally, never mind. Manually had to add the provided cron.service file to /etc/systemd/system/ (but first set the cron path properly in it, 'which cron' gives that of course). Then issue: systemctl enable cron.service ...and if not wanting to reboot first time, just start it with systemctl start cron.service now works just fine, both as root and nemo! Thanks juiceme for your nice work!
Larswad ( 2014-07-08 14:24:06 +0200 )editwell, I have packaged it as a SRPM, compiling & installing & setting up the service. (did it mainly as an exercise, my first service program block on Sailfish...)
It is very basic cron, nothing like fcron for example which has loads of more features, but it does what's needed in pretty good way :)
There are few improvements that should be done probably, for example now it wakes up evdery minute to check if anything should be done, when the better way would probably be to calculate the duration for next scheduled event and sleep until that time.
(the cron code actually does this, but the iphb call only sleeps for a minute...=
juiceme ( 2014-07-08 17:21:42 +0200 )editThanks for the answer. If you actually already have it that nice with an rpm, would you mind adding it to Warehouse? Its a nice addition, because I never got the fcron working properly that nieldk put up there.
I have now set it to do my backup script once every day at 00:00, if the WLAN is up and at my own home wlan and if the battery is > 10 % or if it is in the charger. It will rsync to my server my pictures and videos, later on documents and stuff. Hope the one-minute checks doesn't drain too much though.
Larswad ( 2014-07-08 18:39:23 +0200 )editDoes Warehouse allow SRPM's, or is it for RPM's only?
See, I have an ideological aversion for distributing binaries unless I really have to; building a SRPM is almost as quick as installing a binary RPM, and distributing SW with source form enables you to actually check what is the stuff you are installing for possible baddies.
I, for example do not install any random RPM's to my device, I either download from store or build from source myself. This is a practice I suggest everyone should adopt.
Here's my package: http://www.swagman.org/juice/vixie-cron-3.0pl1-1.src.rpm
juiceme ( 2014-07-08 20:05:51 +0200 )editHow about fcron? https://openrepos.net/content/nieldk/fcron (needs some permission stuff though)
Btw. I tested this basic cron package today and it is working flawlessly.
There was an issue in vixie-cron that was found in XperiaX altough it also exists in other devices.
(see https://together.jolla.com/question/179342/curl-in-crontab-empty-output/ for the problem)
I have now fixed the bug and updated binaries are available here;
And eventually in openrepos too when @ade gets around updating the files.
systemd timers are what you need. I have implemented this. it's simple. all you need is a .timer file and a .service file in /etc/systemd/system
the timer file is the one you enable and start. the timer file references the service file.
You must to know that a systemd timers are not working when phone in sleep mode.
zaharov.andrei ( 2015-01-19 20:45:45 +0200 )editI met this problem also in my app Rush Hour in OpenRepos. I want to update the xml data from the server say in every three minutes. Qml timers slow down disabling to achieve my target. After many trial and error I ended this solution.
Create a DBusAdaptor in qml:
DBusAdaptor {
id: dbus
bus: DBus.SessionBus
service: 'as.kiu'
iface: 'as.kiu'
path: '/'
//dbus-send --session --type=method_call --dest=as.kiu / as.kiu.update
function update() {
loadXmlIdle.start()
}
}
That adaptor starts the timer loading the data. Then create QProcess header to be able to make the call as follows from qml:
fupdater.start("timedclient-qt5",["-awhenDue;runCommand=dbus-send --session --type=method_call --dest=as.kiu / as.kiu.update", "-eAPPLICATION=Rush_hour;TITLE=Wake_up;ticker=180"]);
The code is in github. If you find it useful, please start reading from file: https://github.com/Rikujolla/trafficviewer/blob/dev011/qml/harbour-trafficviewer.qml
This thread is public, all members of Together.Jolla.Com can read this page.
Asked: 2014-01-17 22:24:57 +0200
Seen: 4,663 times
Last updated: Jun 27 '18
probadly not simply because cron is not optimized for embedded.
mike7b4 ( 2014-01-17 22:41:13 +0200 )editSystemd-cron exists but it requires sytemd 197
R. ( 2014-01-18 02:01:40 +0200 )edit@R.: This comment https://together.jolla.com/question/15563/add-more-systemd-components/#post-id-15566 indicates Jolla is going to upgrade systemd in the future. It's still not clear to which version, though.
ossi1967 ( 2014-01-18 16:11:06 +0200 )edit@ossi1967: Yes, you're right. As you can see I was the one who asked the question in your link. I only meant we will have to wait for systemd 197, which was a big release with many features
R. ( 2014-01-18 18:32:04 +0200 )edit