We've got several bugs relating to choosing a new default cron daemon, and/or supporting other alternatives. The contenders seem to be: dcron, bcron, fcron, vixie-cron. I have collected facts about these alternatives below, in the hopes we can make a decision and move forward. Some of these are based on things others have said, so they are reliable to the extent such usually-reliable people made reliable statements; please point out any errors if you spot them! My fact-based inquiry suggests that if we have to select ONE cron, bcron is the best default cron for Arch, because: * vixie-cron is the de facto standard for cron, and thus "vanilla" * bcron is committed to full vixie-cron compatibility * bcron is designed for simplicity and security * modest standard features and high robustness meets most of the community's need If we decided to support two crons, my analysis suggests the other should be fcron. It's already maintained by Sergej in community; we could move it to extra as a second supported choice. What do others think? Tpowa, as maintainer of dcron, what do you think? It would be good for us to make a decision so we can move forward on the course of action and resolve some of these lingering bugs. Do others have specific experiences with bcron to relate? I know some folks like Dan and Thomas have chosen fcron, and maybe for good reason other than just features; if you have war stories, please share. If there's no new info by 1/10, I will start maintaining bcron in [extra] and start using it for my own systems, to assess its suitability firsthand and over an extended time period. - P *** dcron http://apollo.backplane.com/FreeSrc/ ----- advantages: * it's the least work (the incumbent) * simple, small, mature * familiar/standard crontab format disadvantages: * does not log to syslog * does not support /etc/cron.d bcron http://untroubled.org/bcron/bcron.html ----- advantages: * designed with security in mind * full vixie-cron crontab compatibility * compensates for DST * logs to syslog * supports /etc/cron.d disadvantages: fcron http://fcron.free.fr/ ----- advantages: * feature-rich, if/when you want it * almost fully supports vixie-cron syntax (except @*) * compensates for system downtime * already a package in community * Dan and Thomas use it and recommend it firsthand * logs to syslog disadvantages: * does not support /etc/cron.d * slightly larger, more code * not fully vixie-cron compatible * probably less secure, since it's much more extensive vixie-cron ftp://ftp.isc.org/isc/cron/ ----- advantages: * a "reference" implementation, widely known * logs to syslog disadvantages: * not updated (2004)
Paul Mattal wrote:
We've got several bugs relating to choosing a new default cron daemon, and/or supporting other alternatives. <snip>
I thought we decided on fcron with the small adjustment/script needed to support /etc/cron.d in the last round of discussion about this. bcron was also popular (+1 from me...) but then we need an anacron replacement too (i.e. fcron). Aaron has repeatedly called for someone to deal with this and we have had a total of zero volunteers to do so... So if you are going to do this then it would be great. (also have a look at mailman in svn trunk if you have time :P ) Allan
On 01/03/2010 10:28 PM, Allan McRae wrote:
Paul Mattal wrote:
We've got several bugs relating to choosing a new default cron daemon, and/or supporting other alternatives. <snip>
I thought we decided on fcron with the small adjustment/script needed to support /etc/cron.d in the last round of discussion about this. bcron was also popular (+1 from me...) but then we need an anacron replacement too (i.e. fcron).
Is there also an issue we're trying to solve with anacron? Can't we use bcron (or any other cron for that matter) and still use anacron separately? I understand that fcron could theoretically do the work of both, but don't see an inherent advantage over two separate tools which might each be better at their own job. - P
Paul Mattal wrote:
On 01/03/2010 10:28 PM, Allan McRae wrote:
Paul Mattal wrote:
We've got several bugs relating to choosing a new default cron daemon, and/or supporting other alternatives. <snip>
I thought we decided on fcron with the small adjustment/script needed to support /etc/cron.d in the last round of discussion about this. bcron was also popular (+1 from me...) but then we need an anacron replacement too (i.e. fcron).
Is there also an issue we're trying to solve with anacron? Can't we use bcron (or any other cron for that matter) and still use anacron separately?
I understand that fcron could theoretically do the work of both, but don't see an inherent advantage over two separate tools which might each be better at their own job.
Is anacron still maintained? A quick search leads me to think that the last release was in 2000. There is also yacron (maintained by an Arch user) which does everything: http://bbs.archlinux.org/viewtopic.php?id=78654 Allan
On Sun, Jan 3, 2010 at 9:28 PM, Allan McRae <allan@archlinux.org> wrote:
Paul Mattal wrote:
We've got several bugs relating to choosing a new default cron daemon, and/or supporting other alternatives.
<snip>
I thought we decided on fcron with the small adjustment/script needed to support /etc/cron.d in the last round of discussion about this. bcron was also popular (+1 from me...) but then we need an anacron replacement too (i.e. fcron).
Aaron has repeatedly called for someone to deal with this and we have had a total of zero volunteers to do so... So if you are going to do this then it would be great. (also have a look at mailman in svn trunk if you have time :P )
Allan is correct here. We looked it over and based on the responses from all devs at the time, decided that fcron is the best in terms of modernizing our cron. If anyone would like to upgrade our cron to something better, let's go with fcron. Please check the mail archives and bug reports for all the discussion about alternative crons and why fcron was decided. I don't recall all the reasons, but I know they are all there.
On Mon, Jan 4, 2010 at 9:51 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Sun, Jan 3, 2010 at 9:28 PM, Allan McRae <allan@archlinux.org> wrote:
Paul Mattal wrote:
We've got several bugs relating to choosing a new default cron daemon, and/or supporting other alternatives.
<snip>
I thought we decided on fcron with the small adjustment/script needed to support /etc/cron.d in the last round of discussion about this. bcron was also popular (+1 from me...) but then we need an anacron replacement too (i.e. fcron).
Aaron has repeatedly called for someone to deal with this and we have had a total of zero volunteers to do so... So if you are going to do this then it would be great. (also have a look at mailman in svn trunk if you have time :P )
Allan is correct here. We looked it over and based on the responses from all devs at the time, decided that fcron is the best in terms of modernizing our cron.
If anyone would like to upgrade our cron to something better, let's go with fcron. Please check the mail archives and bug reports for all the discussion about alternative crons and why fcron was decided. I don't recall all the reasons, but I know they are all there.
Though, I must admit, I did not see this email until after I replied. yacron was not evaluated when we looked into this... On Mon, Jan 4, 2010 at 6:00 AM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
Hi, I'm the author/maintainer of yacron. It handles @daily, @weekly, @reboot etc. flags. It also handles more fine-grained instructions, like "try to run once a day, but only between the hours of 2-6 am" (that's not how you word the instruction, but that's what it does).
It handles the /etc/cron.d scripts automatically. The /etc/cron.hourly etc scripts are handled the same way dcron handles them, by having lines like this in the system crontab:
@hourly ID=sys-hourly cd / && /usr/bin/run-parts --report /etc/cron.hourly
fcron is more powerful but it's also a lot more complex, more complexity than I needed. I forked dcron into yacron because I thought with a little work I could add the extra features I needed but still keep to the tiny codebase. At this point, the upside of yacron is that simplicity (for however much you value it). The downside is---I'll be honest---not many people have been using it. But then I've had no problem reports, the code is really tiny and I tested/scrutinized my changes carefully, and the dcron starting point is quite mature.
On 01/03/2010 08:52 PM, Paul Mattal wrote:
Do others have specific experiences with bcron to relate? I know some folks like Dan and Thomas have chosen fcron, and maybe for good reason other than just features; if you have war stories, please share.
Several other relevant items have come to my attention, so I'm sharing: 1. fcron supports /etc/cron.d via a script which collects those entries into its own format. The script is out-of-date enough to recommend using dnotify to run it, but perhaps it would be efficient enough otherwise-employed. 2. Jim Pryor has forked dcron 3.2 as yacron. This is a new option: yacron http://repo.or.cz/w/yacron.git ----- advantages: * little work (fork of existing dcron) * simple, small, mature * familiar/standard crontab format (even more like vixie) * supports /etc/cron.d * logs to syslog disadvantages: * not widely tested I'd really feel more comfortable pushing this if it were more tested, but that's a catch-22, I guess. Jim states he's willing to support and update yacron in response to feedback and new upstream dcron releases, should they come. 3. dcron apparently does support /etc/cron.d from 3.1 on, so that was inaccurate in my original roundup. (thanks for pointing that out, Jim) - P
Am Montag 04 Januar 2010 schrieb Paul Mattal:
On 01/03/2010 08:52 PM, Paul Mattal wrote:
Do others have specific experiences with bcron to relate? I know some folks like Dan and Thomas have chosen fcron, and maybe for good reason other than just features; if you have war stories, please share.
Several other relevant items have come to my attention, so I'm sharing:
1. fcron supports /etc/cron.d via a script which collects those entries into its own format. The script is out-of-date enough to recommend using dnotify to run it, but perhaps it would be efficient enough otherwise-employed.
2. Jim Pryor has forked dcron 3.2 as yacron. This is a new option:
yacron http://repo.or.cz/w/yacron.git ----- advantages: * little work (fork of existing dcron) * simple, small, mature * familiar/standard crontab format (even more like vixie) * supports /etc/cron.d * logs to syslog disadvantages: * not widely tested
I'd really feel more comfortable pushing this if it were more tested, but that's a catch-22, I guess. Jim states he's willing to support and update yacron in response to feedback and new upstream dcron releases, should they come.
3. dcron apparently does support /etc/cron.d from 3.1 on, so that was inaccurate in my original roundup. (thanks for pointing that out, Jim)
- P
I'm pretty undecided here, i took cron because it was orphaned a real long time ago. I would be happy if someone could take this cron stuff, because i don't use cronjobs on any of my machines. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
When a crontab is missed due to system downtime, sometimes you want the crontab to be done when the system boots up, but sometimes you do not want that at all. (eg a cleanup crontab that should never run during peak hours) would be nice if the choosen cron solution supports a certain marker per cron entry where you can define the behavior you want. this is a small thing which can be workarounded manually, I know. but still.. Dieter
On 01/04/2010 02:43 AM, Tobias Powalowski wrote:
Am Montag 04 Januar 2010 schrieb Paul Mattal:
On 01/03/2010 08:52 PM, Paul Mattal wrote:
Do others have specific experiences with bcron to relate? I know some folks like Dan and Thomas have chosen fcron, and maybe for good reason other than just features; if you have war stories, please share.
Several other relevant items have come to my attention, so I'm sharing:
1. fcron supports /etc/cron.d via a script which collects those entries into its own format. The script is out-of-date enough to recommend using dnotify to run it, but perhaps it would be efficient enough otherwise-employed.
2. Jim Pryor has forked dcron 3.2 as yacron. This is a new option:
yacron http://repo.or.cz/w/yacron.git ----- advantages: * little work (fork of existing dcron) * simple, small, mature * familiar/standard crontab format (even more like vixie) * supports /etc/cron.d * logs to syslog disadvantages: * not widely tested
I'd really feel more comfortable pushing this if it were more tested, but that's a catch-22, I guess. Jim states he's willing to support and update yacron in response to feedback and new upstream dcron releases, should they come.
3. dcron apparently does support /etc/cron.d from 3.1 on, so that was inaccurate in my original roundup. (thanks for pointing that out, Jim)
- P
I'm pretty undecided here, i took cron because it was orphaned a real long time ago. I would be happy if someone could take this cron stuff, because i don't use cronjobs on any of my machines.
I will take over dcron. We're hoping to replace it soon, but in the interim, I will knock out simple bugs like the optdepend. Best, Paul
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Dieter Plaetinck
-
Paul Mattal
-
Tobias Powalowski