[arch-general] Myths and reality about cronie

Dieter Plaetinck dieter at plaetinck.be
Fri Apr 22 04:01:34 EDT 2011


On Fri, 22 Apr 2011 10:53:31 +0300
Ionut Biru <ibiru at archlinux.org> wrote:

> On 04/22/2011 07:23 AM, Heiko Baums wrote:
> > Am Thu, 21 Apr 2011 21:07:35 -0400
> > schrieb Kaiting Chen<kaitocracy at gmail.com>:
> >
> >> First of all the cronie in [community-testing] is compiled with
> >> --enable-anacron. It installs not only an /etc/crontab but also an
> >> /etc/anacrontab. Scripts in '/etc/cron.hourly' are run directly by
> >> `/usr/sbin/crond` while scripts in '/etc/cron.daily',
> >> '/etc/cron.weekly', and '/etc/cron.monthly' are run by indirectly
> >> by `/usr/sbin/crond` through `/usr/sbin/anacron`.
> >
> > And this is one of the main problems with cronie. It needs a
> > separate /etc/anacrontab for anacron jobs. And this makes it more
> > complicated as necessary. Fcron only needs one fcrontab for every
> > job. To use the anacron feature it just needs to be added a
> > "&bootrun" in front of the line. This way tasks are run as usual
> > cron jobs if the system is up and as anacron jobs if the system is
> > down. This fits all needs in one, the needs of 24/7 servers and the
> > needs of desktop systems.
> >
> > Cronie is nothing else than two different daemons, cron and
> > anacron, put into one binary but with exactly the same complicated
> > functionality and configuration.
> >
> > And the scripts in /etc/cron.{hourly,daily,weekly,monthly} are run
> > directly by fcron, too. And by default there is a "&bootrun" in
> > front of the fcrontab lines which tell fcron when to run those
> > scripts.
> >
> > Another point: fcron is very well documented while there's no
> > documentation about cronie, not even a feature list and comparison.
> >
> > Heiko
> 
> what about crons that are added by users? How they will be migrated
> to fcron or cronie?
> 
> dcron stores the files in /var/spool/cron
> fcron stores them in /var/spool/fcron
> 
> Now you see why i do not like a replaces approach?  I do not want to 
> mess with crons installed by users and broke them with some hacky 
> migration script

you know what would be reeaally cool?
A cron daemon that can read user crontabs from $HOME/.config/crontab or
something.  I think all user-specific stuff should be in $HOME,
although it would probably require a posix acl to allow the cron daemon
reading from there (or making the permissions less strict)

Dieter


More information about the arch-general mailing list