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 Mon, Jan 4, 2010 at 9:51 AM, Aaron Griffin wrote:

On Sun, Jan 3, 2010 at 9: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).

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 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.

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

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