Les Mikesell wrote: > 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. > You may want to run "man cron", or look at the history of cron. Maybe even read the POSIX standard that covers it. Also, if you read the crontab man page, it says it is for editing the "user's" crontab entry. Why would a command to edit user's crontab entries change system crontab entries? I especially like this line from the crontab man page: This description of crontab is designed to support only users with normal privileges. Maybe you should file a bug report because crontab does not generate an error when run as root? Just because you could use crontab -e instead of doing a proper job of configuring system cron jobs doesn't mean you should do so. >> 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. > Arbitrary? Sure. Most of the file locations used in Linux are arbitrary. After all, do we really need /bin, /usr/bin, /usr/X11R6/bin, and /usr/local/bin? We could put all the programs we want users to be able to run by default in /bin. You may want to read the Linux-Filesystem-Hierarchy some time. It is full of arbitrary locations for things. It even specifies things like the directories for system cron jobs. Funny thing - it talks about the /etc/cron.d, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly directories, and the /etc/crontab file. >> It only does if you have no knowledge of the way RH/FC >> does things. > > Or if you expect it to be consistent. > Or if you expect it to follow the LFH specs. >> 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. > I don't understand - are you complaining that system cron jobs are broken up into smaller files, or not? Or are you complaining because system cron jobs and user cron jobs are in different places? What next, complaining because root's home directory is not in /home like the user's home directories? You might want to look at the reason for things like this. (/etc can be mounted read-only, so the user-editable files end up in the /var tree. Home may be on its own partition, and not mounted in the single user mode.) >> 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? > If a user has the need for the same functionality, they can implement it as well. There is nothing preventing a user from creating the same structure in their home directory, and adding the run-parts command to their own crontab. The only thing they can not duplicate is the ability to run cron jobs as other users, or the function of the /etc/cron.d directory. Then again, they should not have enough cron jobs to require it. >> 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? > Yes, you could set things up so that it happens. For that matter, with the current setup, you could have an hourly and a dayly job running at the same time fairly easily. After all, hourly jubs start 1 minute after the hours, and daily start at 04:02, so if it takes more then a minute to process all the hourly jobs, you will still have an hourly job running when the first daily job starts. But you only get 1 of each running at the same time. As a >> 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. > The system cron jobs are installed as part of the package they are needed for. Why would you need to know where they are or edit them? If you have not done enough research to know what affect your changes are going to have on the system, then you probably should not be changing things. If you have done the research, then you should know where to find the files. Reading the LFH or the cron man page will tell you the locations. Or are you saying that there should be a nice GUI to let you shoot yourself in the foot? A GUI can make sure that the changes are in the correct format, but how does it make sure the changes are correct for your system? Running the system cron jobs at 18:00 local time would probably work well at a location where everyone goes home at 15:00, and you have people starting at 03:00. It would not work well for a web server that gets most of its traffic around that time. We are not far enough along with AI programs for a GUI to handle that. > 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? > Hunt all over the place to find them? If you can not find them after reading the cron man page, are you sure you should be messing with them? While the cron man page does not cover /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly, the LFH does. If you do not know about the LFH, you should be able to figure out what the directories do by reading /etc/crontab, if the directorie names are not enough of a clue. After all, this is not Windows - Linux does not claim you can administer everything with a point & click interface without having to learn how things work. For some things, you have to be willing to learn enough to make informed choices, accept the defaults, or get someone that has the knowledge to make the changes for you. For the average desktop user, the defaults are probably going to work fine. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
