[arch-dev-public] Cron Plan
Having now learned more about cron and its many flavors than I probably ever wanted to know, I am prepared to suggest a course of action. I've picked up maintenance of dcron from tpowa, and am prepared to move forward. If we can reach agreement, I'll do the work. I understand there was a previous decision made to move to fcron. However, yacron (a slightly-less-minimal dcron fork) was known and considered at the time, so it makes sense to consider it now. In the last few days, the yacron author, Jim Pryor, has been blessed by Matt Dillon as the new dcron maintainer, thus unforking: http://apollo.backplane.com/FreeSrc/ http://www.jimpryor.net/linux/yacron.html This new yacron/dcron 4.0 option is pretty attractive. advantages: * simple, small, mature, designed with security in mind * maintained by an Arch user * familiar/standard crontab format * supports anacron-type behaviors * supports /etc/cron.d (more effectively than fcron) * can log to syslog disadvantages: * may not provide all the advanced/anacron-type behavior fcron does * not all of the newly-merged code changes are widely tested Proposal: We stay with dcron into the 4.0 series, with a longer-than-usual testing window so the transition is smooth, and see if it meets our collective needs. Jim may be willing to add functionality we find lacking. Please get your votes and comments in by the weekend, if possible. I'd like to move on this next week, if we have agreement. Thanks! - P
On Wed, Jan 6, 2010 at 12:09 AM, Paul Mattal <paul@mattal.com> wrote:
Having now learned more about cron and its many flavors than I probably ever wanted to know, I am prepared to suggest a course of action. I've picked up maintenance of dcron from tpowa, and am prepared to move forward. If we can reach agreement, I'll do the work.
I understand there was a previous decision made to move to fcron. However, yacron (a slightly-less-minimal dcron fork) was known and considered at the time, so it makes sense to consider it now.
In the last few days, the yacron author, Jim Pryor, has been blessed by Matt Dillon as the new dcron maintainer, thus unforking:
http://apollo.backplane.com/FreeSrc/ http://www.jimpryor.net/linux/yacron.html
This new yacron/dcron 4.0 option is pretty attractive.
advantages: * simple, small, mature, designed with security in mind * maintained by an Arch user * familiar/standard crontab format * supports anacron-type behaviors * supports /etc/cron.d (more effectively than fcron) * can log to syslog disadvantages: * may not provide all the advanced/anacron-type behavior fcron does * not all of the newly-merged code changes are widely tested
Proposal: We stay with dcron into the 4.0 series, with a longer-than-usual testing window so the transition is smooth, and see if it meets our collective needs. Jim may be willing to add functionality we find lacking.
Please get your votes and comments in by the weekend, if possible. I'd like to move on this next week, if we have agreement.
I think this is a pretty good idea that seems to have solved itself. Props to Jim Pryor for this
Am 06.01.2010 07:09, schrieb Paul Mattal:
* supports anacron-type behaviors
Can you elaborate on that? All I want is that a "missed" daily/weekly/monthly cron job is executed after boot on a machine that's not always-on. That's why I use fcron, nothing more. Will that be possible with the new dcron?
On 01/06/2010 12:59 PM, Thomas Bächler wrote:
Am 06.01.2010 07:09, schrieb Paul Mattal:
* supports anacron-type behaviors
Can you elaborate on that? All I want is that a "missed" daily/weekly/monthly cron job is executed after boot on a machine that's not always-on. That's why I use fcron, nothing more. Will that be possible with the new dcron?
Based on Jim's description in his list of "highlights" on the new homepage, it does this: * accepts @daily, @reboot, etc. options in crontabs; @daily jobs don't require the machine to be running at any specific time Sounds like it also does some more sophisticated variants on this, if you only want it run in a particular window, for example: http://www.jimpryor.net/linux/yacron.html - P
On 01/06/2010 01:09 AM, Paul Mattal wrote:
Proposal: We stay with dcron into the 4.0 series, with a longer-than-usual testing window so the transition is smooth, and see if it meets our collective needs. Jim may be willing to add functionality we find lacking.
Please get your votes and comments in by the weekend, if possible. I'd like to move on this next week, if we have agreement.
I've just placed dcron 4.2 into [testing]. This is a major update to dcron, under a new maintainer (who is an Arch user, and very responsive). With this release, I am also taking over maintaining dcron in [core]. I'd like to get 2 signoffs for each architecture for this one, since it represents a lot of new functionality. Full changelist since 3.2 inlined below. For further info, and a full git history, see: http://www.jimpryor.net/linux/dcron - P *** For more information, v4.2 11-Jan-2010 * Makefile tweaks; moved more constants to #defines. v4.1 10-Jan-2010 * Fixed bug in parsing some numeric fields in crontabs. (Terminus of range wasn't being modded.) * Updated Makefile to make it easier to customize timestamps at configure time. Also, if LC_TIME is defined when crond runs, we use that instead of compiled-in default (for logging to files, to customize syslog output use syslog-ng's 'template' command). * Fixed Makefile permissions on crond and crontab binaries. v4.0 6-Jan-2010 * Jim Pryor took over development; folded in changes from his fork "yacron" * Applied "Daniel's patch" from dcron 3.x tarballs to enable logging to syslog or files. Added further logging improvements. * Added -m user@host and -M mailer options * Various crontab syntax extensions, including "2nd Monday of every month", @reboot, @daily, and finer-grained frequency specifiers. * Jobs can wait until AFTER other jobs have finished. * Enhanced parsing of cron.update file, to make it possible for scripts to interact with a running crond in limited ways. * Various internal changes * Updated Makefile, manpage buildchain, and docs
On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal <paul@mattal.com> wrote:
On 01/06/2010 01:09 AM, Paul Mattal wrote:
Proposal: We stay with dcron into the 4.0 series, with a longer-than-usual testing window so the transition is smooth, and see if it meets our collective needs. Jim may be willing to add functionality we find lacking.
Please get your votes and comments in by the weekend, if possible. I'd like to move on this next week, if we have agreement.
I've just placed dcron 4.2 into [testing]. This is a major update to dcron, under a new maintainer (who is an Arch user, and very responsive). With this release, I am also taking over maintaining dcron in [core].
I'd like to get 2 signoffs for each architecture for this one, since it represents a lot of new functionality. Full changelist since 3.2 inlined below. For further info, and a full git history, see:
http://www.jimpryor.net/linux/dcron
- P
***
Why did you put etc/rc.d/crond in the backup array? These daemon scripts are not intended to be modified by the user. If you want them to be able to pass different options, you should use a /etc/conf.d/crond config file. Eric
participants (4)
-
Aaron Griffin
-
Eric Bélanger
-
Paul Mattal
-
Thomas Bächler