aaronmgriffin at gmail.com
Mon Jan 4 10:52:45 EST 2010
On Mon, Jan 4, 2010 at 9:51 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Sun, Jan 3, 2010 at 9:28 PM, Allan McRae <allan at archlinux.org> wrote:
>> Paul Mattal wrote:
>>> We've got several bugs relating to choosing a new default cron daemon,
>>> and/or supporting other alternatives.
>> 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 at 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.
More information about the arch-dev-public