Among his selling points for fcron were that if the computer was powered off during the time a cronjob was scheduled to execute, one could have fcron execute it at the next system start-up instead.
That does indeed seem nifty, but as the really important cronjobs of mine are running on my laptop-turned-server, whose task it is to be up 24/7, those selling points seemed… unnecessary.
But as I had promised I would at least look into it (it didn’t hurt the slightest that hook graciously provided me with a wealth of information about fcron in the form of an article (in German, watch out for Google Translate, it WILL mangle the example fcron syntax in the article) he’d authored, and a post about his own fcrontab).
So I started reading about fcron, and it did indeed seem really nice, but I remained sceptical since dcron was providing me with everything I needed.
One thing I don’t feel is stressed enough in the resources which I have read about fcron is that old dcron entries WILL WORK, out of the box, in fcron as well.
That was a big stumbling block for me personally, the outlook of having to rewrite the entries in my crontab so that they would work in fcron.
Once I realized this wasn’t the case, I warmed up to fcron significantly. I decided to install it on my netbook first, to try it out and get acquainted with it.
From what I have come to understand, fcron can understand three types of syntax; the regular (as seen in dcron) “date specification-based” syntax, a “relative from system boot”-based syntax, and finally the “*ly”-based syntax (hourly, daily, weekly, etc.)
The “relative to system boot”-syntax is pretty smart, and I will probably use that a whole lot, while the “*ly”-syntax seems to me to increase the readability of when stuff will happen, but decrease control over when they actually happen (it would seem fcron only guarantees that a job scheduled to get executed “daily” will be executed daily, some time within the time span of the “day hours”.
I’m sure I will find uses for that type of rules as well, and as one can note from hook’s post, the “*ly”-syntax is the one he use the most.
fcron brings more than this to the table however. One can add options, either to individual entries, or globally.
It wasn’t until I came across these options, and started reading up on them, that I realized that adopting fcron would go down as my best decision of this month.
There are plenty of options, I suggest the MAN page (fcrontab(5)) for reading them all, but the ones that caught my eye for various reasons are:
- bootrun – for making jobs run at start if they should have ran during downtime
- first(X) – delay execution of “relative to boot” entry for X minutes
- lavg(X, Y, Z) – I am not quite clear about how this work, yet, but if the load average (coincidentally I read a great post the other day which explained load averages pretty well (be sure to read the comments though)) is too high, the job is either not carried out, or queued for later execution
- runas – (only available for root) Have the job execute as another user
Finally, there is one more option of significance to me. The one that makes fcron the best decision of the month: timezone(Continent/City).
Say that you, like me, live in Sweden (timezone Europe/Stockholm) and wish to send an automated good morning message to a friend in New York every morning at 0800 hours. (Yes, this is a VERY contrived example, you’ll have to use your own imagination as to why this might be cool)
If I’d set cron to just send the message at 0800 (Swedish local time) that would be 0200 hours over in New York. Of course, the arithmetic isn’t hard, I could just subtract the six hour time difference and be on my merry way… until daylight savings time… Reading up on that I realize that Europe and the US don’t switch on the same dates, and from what I can gather, not even during the same week.
fcron‘s ability to execute jobs based on a time specification, given the time in another timezone, makes this a complete non-issue (the lines about timezone in fcrontab(5) doesn’t mention it handling DST, but below it there is documentation for the old (which should NOT be used) tzdiff option, which states that tzdiff is stupid, can’t handle DST, but the timezone option will.
And that’s about it, all that is left for me is to again extend a big thank you to hook for recommending it. Rest assured that it has helped me save some time