[gentoo-dev] Inotify and (f)crontabs

[Ryan Reich]

On 7/7/07, Mike Frysinger <vapier@g.o> wrote:
> On Sunday 01 July 2007, Ryan Reich wrote:
> > This is a small essay on Gentoo's setup for fcron.
>
> which is troublesome because some of the things here are specific to fcron
> (which frankly dont interest me) while others are specific to the cronbase
> package which installs `run-crons` (which does interest me as it is a
> Gentooism) ... i'll try to pick out only the relevant pieces as you said
> yourself, the fcron things should go upstream.

I'm sorry you don't care about my fcron criticisms, but that's the
cron I use so it's the one I picked on.  The problems with
check_system_crontabs were only half the point, anyway.

> > 2. is implmented by putting the following rules in /etc/crontab:
> >     0  *  * * *      rm -f /var/spool/cron/lastrun/cron.hourly
> >     1  3  * * *      rm -f /var/spool/cron/lastrun/cron.daily
> >     15 4  * * 6      rm -f /var/spool/cron/lastrun/cron.weekly
> >     30 5  1 * *      rm -f /var/spool/cron/lastrun/cron.monthly
> >     */10  *  * * *      /usr/bin/test -x /usr/sbin/run-crons &&
> > /usr/sbin/run-crons
> > whose effect is, at intevals of one hour, day, week, and month, to
> > remove some state files for the script run-crons, and also to run said
> > script every ten minutes.  The purpose of run-crons is to run the
> > scripts in /etc/cron.{hourly,...} at the appropriate intervals, thus
> > saving me the effort of adding a lot of lines looking like
> >     1 3 * * * * some-command
> > to my crontab.
>
> you missed a critical aspect: offline time.  the way run-crons is implemented,
> if you happen to routinely shut your machine off at the time that the cronjob
> is supposed to fire, then the standard you proposed will pretty much never
> fire.  the run-crons implementation however has a pretty good guarantee that
> the periodic crons will get fired at the next uptime opportunity.

This point is where your uninterest in fcron puts us at odds.  See,
fcron allows you to have such commands run at boot, and allows you to
schedule commands that run at periods of uptime rather than wall time,
so this is not an issue for fcron.  And for other crons, there exists
anacron, which is recommended precisely for this purpose by Gentoo.
The only thing that's accomplished by putting this functionality in
run-crons is to duplicate it, awkwardly.

> > Furthermore, the files /var/spool/cron/lastrun/cron.* are
> > ALREADY handled in the run-crons script itself, so that most of the
> > above commands would seem to be redundant.
>
> this is most likely true.
>
> > This one also has the
> > additional unpleasant property of filling the logs with useless
> > messages:
> >     [fcron] Job /usr/bin/test -x /usr/sbin/run-crons &&
> > /usr/sbin/run-crons started for user
> >     systab
>
> yes, this sucks, but so it goes.

So if it sucks, you would approve of an alternative that doesn't
exhibit this behavior?

--
Ryan Reich
-- 
gentoo-dev@g.o mailing list