[arch-general] Change Arch's default crond

[Thomas S Hatch]

On Wed, Apr 6, 2011 at 4:29 PM, Heiko Baums <lists at baums-on-web.de> wrote:

> Am Wed, 6 Apr 2011 15:30:26 -0600
> schrieb Thomas S Hatch <thatch45 at gmail.com>:
>
> > dcron and fcron are not under active development,
>
> fcron is under active development. It's just feature complete and
> therefore not developed anymore, but bugs are still fixed if they
> occur. So don't mix it up with a "dead" project. I guess dcron most
> likely can be assumed to be dead.
>
> > cronie is
> > cronie is small - 0.20MB installed
> > cronie is developed by Red Hat - it is not going anywhere and we have
> > a guaranteed upgrade path
>
> What does that mean? Look at the size and you can see that it can't be
> as feature rich as fcron.
>
> > As far as I can tell cronie has no deps beyond glibc and pam
> > cronie has /etc/cron.d support
> > cronie has configurable anacron support via an anacrontab config file
>
> But you need a separate anacrontab. So it's the same as having
> installed a cron and a separate anacron. With fcron you just need one
> cron daemon which has anacron features integrated. This means you don't
> need to have a separate anacrontab. So you don't need to decide if a
> task needs to be run by cron or by anacron. You just can add every task
> into one single crontab resp. fcrontab and just put &bootrun at the
> beginning of the line as Thomas already explained. This means that this
> task is run at the desired time if the system is up and the cron is
> running, and if not then this task is automagically run as soon as fcron
> is started the next time and that very reliably.
>
> So this is much easier and much more flexible than a separate
> cron/anacron solution.
>
> That's why fcron is still the best.
>
> And neither /etc/cron.d support nor the fact that cronie is developed by
> Redhat is an argument in my opinion.
>
> /etc/cron.d can easily be moved
> to /etc/cron.{hourly,daily,weekly,monthly} or to fcrontab.
> So /etc/cron.d is not needed. So this is not an argument in my opinion.
> I guess this transition takes about 5 to 10 minutes maximum if at all.
>
> > cronie extends the original vixie cron package so the syntax, core
> > feature set, etc are stable
> > cronie implements advanced security hooks as well and can integrate
> > with SELINUX (I am saving the "include SELINUX support in base for a
> > latter date")
>
> Well, is SELinux really a default? Does SELinux run on Arch at all? Is
> this really an argument regarding the decision which cron shall be the
> default.
>
> As said before, the question is not having removed every other cron
> from the repos. The question is about the default cron.
>
> Most people who are regularly discussing this topic here on the mailing
> list tend to fcron for a lot of good reasons.
>
> And the few people who really need /etc/cron.d or SELinux support - I'm
> not sure if fcron is not able to run with SELinux - can easily install
> another cron daemon.
>
> dcron was just kept as the default, because the formerly dead project
> was adopted by an Arch user who said, that he wants do keep developing
> it and to fixing the bugs. As already said the most important bug wasn't
> fixed in a year. And in the meantime it was nothing heard from this
> Arch user anymore. So it can be assumed dead in my opinion.
>
> > At the outset I think that cronie looks to be the most viable option,
> > but merits further investigation.
>
> I definitely still vote for fcron for reason which have been explained
> many times here on the list - not only by me.
>
> Alternatively it can be done as it is already done with the boot
> manager in AIF that every cron is listed in the package list so that
> the user can decide which one to install or AIF brings a separate
> dialog which asks the user which cron daemon to install with a small
> or a bit more detailed description of the daemons.
>
> Heiko
>

All I said what that cronie merits investigation, and that there are good
reasons to investigate. Also, the size of a package != feature set. The
argument that Red Hat develops it is only a plus in that is ensures ongoing
development of the project of provisions to migrate to something else in the
future, just because Red Hat develops something is not alone a viable reason
to use it over other things, but it is a topic for consideration when making
a decision.

All I want is a good decision to be made and have a crond that is not buggy.
Therefore I think that it is foolish not to present the available options in
an accurate light.