cron

Mikkel L. Ellertson mikkel at infinity-ltd.com
Thu Feb 15 19:55:34 UTC 2007


Les Mikesell wrote:
> 
> Yes, and it's easier for a human to understand and modify things that
> are all in one place and work the same way in all cases.  I'd rather see
> things optimized for humans and let the machines do the extra work...
> It would make sense to make *all* crontabs include the contents of all
> files in a matching crontab.d directory, so whatever benefits for
> automation that style adds would extend to users too, and the crontab
> program could handle it transparently with the -e and -l options.
> 
> It doesn't make much sense to splatter this information around in
> different formats in several different places in files whose names don't
> sort reasonably and that only make sense in one language.  Did some
> windows programmer come up with the scheme?
> 
Well, cron has never had everything in one place. The system cron
jobs have always been in /etc/crontab. They still are. The only
change is that there are cron jobs that run the files in the cron.*
directories at the intervals specified. You could do the same thing
by having the scripts run directly from /etc/crontab. I think it is
easier to see what is going on by looking in /etc/cron.daily to see
what system jobs are run every day. To disable a cron job, without
removing it, you can turn off the execute bit on the file. You could
do the same thing by editing /etc/crontab, and commenting out the
specific line, but I like this approach better. I also like being
able to tell what package added what cron jobs. Trying to do this if
everything was in /etc/crontab would be a nightmare. The fact that
it makes package management simpler is also a good thing. It also
makes changing when the system jobs are run simple - instead of
having to change the tiles for each job, you can change the times
for the entire class of jobs by changing one line in /etc/crontab.
You can also control the order the jobs are run by changing the job
name.

Now, I know Les is going to complain that this makes it harder to
find things. It only does if you have no knowledge of the way RH/FC
does things. This same directory setup is used by most of the
packages that need to be able to change the configuration of another
package. It also makes writing on a GUI to control system cron jobs
a lot easier. (I know how you like point and click configurations
Les.) I would expect to hear the same kind of complaint from Les
about the other .d directories in /etc. After all, profile.d could
be put into bashrc and/or profile. Each of the .d directories could
be in one big config file each. The fact that it makes it harder to
edit, and easier to make a mistake is besides the point, right?

It does not make sense to put user cron jobs in these directories.
They are run at fixed times, and do not allow the fine control that
the individual crontab files allow. They are also run sequentially,
so the job may run later then the user wanted. Depending on where it
falls in the order, it may be MUCH later. Some cron jobs take a
while to run. With the current setup, a user's job can run at the
same time as a system cron job.

It only looks complex if you do not take the time to understand the
underlying structure. But if you do not understand the structure,
you probably should not be messing around with system cron jobs
anyway. By separating the system cron jobs from the user cron jobs,
you make it less likely that the system cron jobs will get changed
by mistake. After all, a user would notice fairly quickly if their
personal cron job was not running. But if you disabled something
like logrotate, you might not notice until /var filled up.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!




More information about the users mailing list