Tomas Mraz <tmraz(a)redhat.com> wrote:
> > attached is a patch to persistently save the times of last
> > runs. I have baked an RPM and installed it on my system and
> > will report in two weeks how reliable it turned out. Com-
> > ments and suggestions are - of course - also welcome ear-
> > lier :-)
> > [...]
> Well, I missed the two weeks marker quite a bit, but I have
> been using the patched cronie for more than four months now
> to my complete satisfaction. I haven't seen any glitches.
> Has there been progress on the plan for future develop-
> ment?
My biggest problem with your patches is that they are really
duplicating
the functionality that's implemented in anacron. It would be much nicer
if cron forwarded the request to run such daily/weekly/monthly jobs to
the anacron. Or - that is another possiblity - we could integrate your
patches and add other functionality that is in anacron and missing in
cron (randomizing job startup times, support for the anacron
configuration format, etc.) into cronie and drop anacron completely from
the cronie codebase. That would be probably even more clean solution but
it requires much more work.
Just some background: I wanted to run daily *user* tasks on
Fedora which neither cronie nor anacron are offering
(
https://bugzilla.redhat.com/show_bug.cgi?id=517753). I
then looked at fcron which promises this functionality, but
stumbled over its incompatibility with SELinux's targeted
policy. I filed a bug
(
https://bugzilla.redhat.com/show_bug.cgi?id=517170) and
created a fix for it, but was told that cronie's SELinux so-
lution should be ported to fcron instead. So rather than
doing this which looked very challenging, I ported (part of)
fcron's functionality to cronie. And here I am now.
So I am all in favour of dropping any resuscitation ef-
forts on fcron and code duplication between cronie and ana-
cron. One advantage of the integration into cronie besides
the engineering side is also that changes in scheduling a
task, e. g. from "14:35 daily" to "once daily", would never
require touching different configuration files with differ-
ent syntaxes.
What I could do, is to push your patches into a separate branch on
fedorahosted, but I don't think that we want to merge them into trunk at
this time.
I don't think that's useful as there doesn't seem to be a
cronie "community" :-), but thanks for the offer.
Tim