Hi,
the attached patch provides some initial fcron-like func- tionality. Given a crontab of:
| %daily */7 * echo daily | %weekly */23 * echo weekly | %hourly */3 echo hourly
it will run:
1. "echo daily" once per calendar day, on the first possi- bility of minute % 7 == 0,
2. "echo weekly" once per calendar week (Monday to Sunday), on the first possibility of minute % 23 == 0, and
3. "echo hourly" once per hour, on the first possibility of minute % 3 == 0.
Periods are reset when crond is started. I haven't actually tested the daily/weekly bits thoroughly as I didn't want to wait :-). I didn't get the indentation quite right as TABs are pure evil.
I'd like to push this to fedorahosted.org in a branch to ease collaboration and thus have applied for the gitcronie group.
In further development, besides writing documentation, I'll add a state file in /var/lib that saves the times of last execution over a reset. For that I'd like to survey what in users' views makes a job "unique". I. e., should the time of last execution of "%daily */7 * echo daily" be based besides the user name on the command ("echo daily"), the command and flattened schedule ("echo daily", "0:00/0:07/0:14/0:21/etc."), the literal crontab line or something else? This is not only interesting for restarts, but also for user crontab reloads.
Tim
Thanks for your patch.
We'd like to: * implement some functionality from fcron * add more options into classical crontab syntax * interconnect anacron more closely with cron I'm not sure if feature proposed in your patch shouldn't go into anacron instead. Please be patient, we'd like to review our plan for future development at first. We need to decide the future syntax to not collide with other planned features.
Best regards, Marcela
On 04/26/2012 02:07 PM, Tim Landscheidt wrote:
Hi,
the attached patch provides some initial fcron-like func- tionality. Given a crontab of:
| %daily */7 * echo daily | %weekly */23 * echo weekly | %hourly */3 echo hourly
it will run:
"echo daily" once per calendar day, on the first possi- bility of minute % 7 == 0,
"echo weekly" once per calendar week (Monday to Sunday), on the first possibility of minute % 23 == 0, and
"echo hourly" once per hour, on the first possibility of minute % 3 == 0.
Periods are reset when crond is started. I haven't actually tested the daily/weekly bits thoroughly as I didn't want to wait :-). I didn't get the indentation quite right as TABs are pure evil.
I'd like to push this to fedorahosted.org in a branch to ease collaboration and thus have applied for the gitcronie group.
In further development, besides writing documentation, I'll add a state file in /var/lib that saves the times of last execution over a reset. For that I'd like to survey what in users' views makes a job "unique". I. e., should the time of last execution of "%daily */7 * echo daily" be based besides the user name on the command ("echo daily"), the command and flattened schedule ("echo daily", "0:00/0:07/0:14/0:21/etc."), the literal crontab line or something else? This is not only interesting for restarts, but also for user crontab reloads.
Tim
Cronie-devel mailing list Cronie-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cronie-devel
Hi Marcela,
Thanks for your patch.
We'd like to:
- implement some functionality from fcron
- add more options into classical crontab syntax
- interconnect anacron more closely with cron
I'm not sure if feature proposed in your patch shouldn't go into anacron instead. Please be patient, we'd like to review our plan for future development at first. We need to decide the future syntax to not collide with other planned features. [...]
No problem. I think that integrating periodic user jobs into anacron would entail reimplementing the whole user in- terface that cronie already has. It would also force the user to classify his jobs into the two categories while with fcron or cronie with an fcron-like functionality he could just use what is already known to him without bothering how they are executed.
Attached is a small patch to document the functionality my initial patch added.
Tim
Hi,
attached is a patch to persistently save the times of last runs. I have baked an RPM and installed it on my system and will report in two weeks how reliable it turned out. Com- ments and suggestions are - of course - also welcome ear- lier :-)
Tim
I wrote a long time ago:
attached is a patch to persistently save the times of last runs. I have baked an RPM and installed it on my system and will report in two weeks how reliable it turned out. Com- ments and suggestions are - of course - also welcome ear- lier :-) [...]
Well, I missed the two weeks marker quite a bit, but I have been using the patched cronie for more than four months now to my complete satisfaction. I haven't seen any glitches.
Has there been progress on the plan for future develop- ment?
Tim
On Thu, 2012-09-06 at 18:11 +0000, Tim Landscheidt wrote:
I wrote a long time ago:
attached is a patch to persistently save the times of last runs. I have baked an RPM and installed it on my system and will report in two weeks how reliable it turned out. Com- ments and suggestions are - of course - also welcome ear- lier :-) [...]
Well, I missed the two weeks marker quite a bit, but I have been using the patched cronie for more than four months now to my complete satisfaction. I haven't seen any glitches.
Has there been progress on the plan for future develop- ment?
My biggest problem with your patches is that they are really duplicating the functionality that's implemented in anacron. It would be much nicer if cron forwarded the request to run such daily/weekly/monthly jobs to the anacron. Or - that is another possiblity - we could integrate your patches and add other functionality that is in anacron and missing in cron (randomizing job startup times, support for the anacron configuration format, etc.) into cronie and drop anacron completely from the cronie codebase. That would be probably even more clean solution but it requires much more work.
What I could do, is to push your patches into a separate branch on fedorahosted, but I don't think that we want to merge them into trunk at this time.
Tomas Mraz tmraz@redhat.com wrote:
attached is a patch to persistently save the times of last runs. I have baked an RPM and installed it on my system and will report in two weeks how reliable it turned out. Com- ments and suggestions are - of course - also welcome ear- lier :-) [...]
Well, I missed the two weeks marker quite a bit, but I have been using the patched cronie for more than four months now to my complete satisfaction. I haven't seen any glitches.
Has there been progress on the plan for future develop- ment?
My biggest problem with your patches is that they are really duplicating the functionality that's implemented in anacron. It would be much nicer if cron forwarded the request to run such daily/weekly/monthly jobs to the anacron. Or - that is another possiblity - we could integrate your patches and add other functionality that is in anacron and missing in cron (randomizing job startup times, support for the anacron configuration format, etc.) into cronie and drop anacron completely from the cronie codebase. That would be probably even more clean solution but it requires much more work.
Just some background: I wanted to run daily *user* tasks on Fedora which neither cronie nor anacron are offering (https://bugzilla.redhat.com/show_bug.cgi?id=517753). I then looked at fcron which promises this functionality, but stumbled over its incompatibility with SELinux's targeted policy. I filed a bug (https://bugzilla.redhat.com/show_bug.cgi?id=517170) and created a fix for it, but was told that cronie's SELinux so- lution should be ported to fcron instead. So rather than doing this which looked very challenging, I ported (part of) fcron's functionality to cronie. And here I am now.
So I am all in favour of dropping any resuscitation ef- forts on fcron and code duplication between cronie and ana- cron. One advantage of the integration into cronie besides the engineering side is also that changes in scheduling a task, e. g. from "14:35 daily" to "once daily", would never require touching different configuration files with differ- ent syntaxes.
What I could do, is to push your patches into a separate branch on fedorahosted, but I don't think that we want to merge them into trunk at this time.
I don't think that's useful as there doesn't seem to be a cronie "community" :-), but thanks for the offer.
Tim
cronie-devel@lists.stg.fedorahosted.org
-
Marcela Mašláňová -
Tim Landscheidt -
Tomas Mraz