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!
