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@xxxxxxxxx
