cron

[Les Mikesell]

Mikkel L. Ellertson wrote:
>>
> Well, cron has never had everything in one place. The system cron
> jobs have always been in /etc/crontab. They still are.

Some unix-like systems have /etc/crontab.  Some don't.  It isn't 
necessary since you can perform the same functions from root's crontab.
"man 1 crontab" says it is the program to use to edit the tables used by 
cron.  It doesn't edit /etc/crontab or its various permutations.

> Now, I know Les is going to complain that this makes it harder to
> find things.

My complaint is that it is arbitrary and inconsistent.

> It only does if you have no knowledge of the way RH/FC
> does things.

Or if you expect it to be consistent.

 > 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?

I don't have a problem with a systematic scheme of breaking individual 
files into xxx.d directories with smaller entries.

> It does not make sense to put user cron jobs in these directories.

Why shouldn't any scheme that is useful at the system level be equally 
useful for each user - and more understandable when it all works the 
same way and has the same format for the entries?  If the system needs a 
cron.d so programs can twiddle the entries easily, why shouldn't users 
each get the same functionality?

> They are run at fixed times, and do not allow the fine control that
> the individual crontab files allow. They are also run sequentially,

Well, sort of... Since it is all arbitrary, there is no coordination 
that prevents an hourly, daily, weekly, and monthly job from all running 
at the same time.  And where's yearly?

> 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.

How so?  If you run crontab -e as a user you can only edit your own 
entries, you don't need to know where it is stored, and the cron process 
is notified when the file changes.

  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.

And the point of separating the system from root jobs so you have to 
hunt all over the place to find them?

-- 
   Les Mikesell
    lesmikesell at gmail.com