On Mon, Jan 4, 2010 at 9:51 AM, Aaron Griffin <[email protected]> wrote: > On Sun, Jan 3, 2010 at 9:28 PM, Allan McRae <[email protected]> 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 <[email protected]> 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.
