Les Mikesell wrote: > Mikkel L. Ellertson wrote: > >> Arbitrary? Sure. Most of the file locations used in Linux are >> arbitrary. > > The ones that were inherited from older systems usually had functional > reasons. The moves and renames since have mostly been arbitrary. > There are functional reasions for the new ones as well - I told you where to find them. If you do not want to know the reason, that is your problem. > >> 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. > > But the resulting changes don't give any new functionality. > They don't? I like being able to find all the system cron jobs that run hourly, daily, etc in predictable places. I know if the job doesn't run as root and/or doesn't run at the normal times, I have to look in cron.d. >> Or are you complaining because >> system cron jobs and user cron jobs are in different places? > > I'm complaining that for any given job, you have no idea where the entry > that controls it would be found, and no way to describe where to look > first. Contrast that to the way entries in /etc/init.d, /etc/pam.d/ or > /etc/xinetd.d are made. For a given service there is a logical place to > find its specific broken-up entry. For scheduled jobs relating to a > service there is no such logic. > Sure there is - if it is a system job, run by root, you can look at when it was started, and know where to look. If it is a user's job, you know where to look. Weekly and monthly jobs complicate it slightly, but not much. >>> >> 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. > > Beg your pardon? The reason I have computers is to do my jobs, not just > so the system can run itself. If cron.d has to be hardcoded somewhere, > why shouldn't I get one too? > Why? If you need it, set it up once, and forget about it. If you have a strange setup where all users need it, set up the structure in /etc/skel, and add creating the crontab file as part of the user setup script. (If you have that type of user base, you need more then useradd to create users anyway.) >> >> 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? > > They might be wrong. They might conflict with something else I have > running. Or I might want to make my own arbitrary changes. > Then you should know enough about your system to know where to find them. You make it sound like they are hard to find. For a system cron job, it is going to be in one of a small number of locations. And if you know it is conflicting, then you know how often it is run, and probably when it is run, so you should know where it is. >> 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? > > The GUI is irrelevant. If there were a sensible scheme to find the > entry controlling a given job a sensible GUI could do it, or you could > do it with any editor. > The scheme doesn't matter if you don't know when a job is run. Changing when hourly, daily, etc jobs are run takes editing one file, and changing one time each. The hard part is knowing the time to use, and that problem is the same regardless of the scheme. Now, if the job doesn't fit nicely into one of the standard frequency folders, then you have to change it in its own file in cron.d, but if it is in there, it should have a reason it is not running at the standard times. (Or the packager made a mistake.) >>> 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? > > If I give you the name of a program or the user id the job runs under, > can you tell me where to find the entry that controls its schedule by > reading any of those man pages or FHS entries you've mentioned? > If I add a scheduled job as administrator myself, could you tell the > next machine administrator where to look to find it and the other jobs > that run as root? Does any of this help you write a script that would > modify a given entry on some unspecified version of a unix-like > operating system? > If you do it? Probably not. If a competent administrator does it, sure. After all, a competent administrator is not going to use crontab -e to create a system job. So I know I will find it in the cron directory structure in /etc. Knowing how often the job needs to run tells me where. If it was installed as part of an RPM package, and I know the package, I can find it that way as well. If an admin does something really oddball, they should document it. Notes in /root/notes are a good idea. Comments in changed config files explaining the change are also a good idea. As far as creating a script, if you are not going to know the os, then you should not be trying to modify a system config file automatically from a script. You can check what os as part of the script, and branch to cover the os. You should also check on the version of cron running on the system. You know - the standard tests you have to make when updating a config file when you do not know what version of the program is going to be on the system. Now, if you are creating a script that is part of a package, and needs cron to run a job for it, you don't have to modify any files on systems that follow the LFH. You just drop the script in the correct directory as part of package install, and remove it as part of the uninstall. Much better then when we used to have to edit /etc/crontab as part of the process. If you are using one of the standard intervals, you don't even have to add the time and user information to your script. Yes, adapting to new ways of doing things can be hard. And sometimes we find after using things for a while that there is a better way. But complaining because things changes, or exaggerating the problem is not the way to improve things. If you have a problem with the way things are done, try using a reasoned explanation of why. Saying that things are scattered "all over the system" when there can all be found off the /etc directory, and the directories even start with cron, is not going to help. Saying that someone can use bad practices so that it is hard for the next person to find them is not going to help ether. (Getting the person to follow the standard may be worth the effort, depending on if they will listen, or insist that their way is the way it should be.) You have a hard time finding where a file is launched from by looking at running processes. I like having all the daily cron jobs in one place - it makes seeing what gets run easy. I don't like when a daily job gets put in /etc/cron.d, because then I have to search the files to find what files get run daily. It isn't a perfect world. Being willing to try new ways, and giving the user a choice of how they do things is part of Linux. If the cron setup bothers you that much, you can always try a different distribution. It works well for a lot of people. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
