Les Mikesell wrote: > Mikkel L. Ellertson wrote: > >>> 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. > > Why would you know how something is scheduled without seeing the entry? > If you don't know how it is scheduled, how do you find it? > If you don't know anything about it, why are you changing it? Changing things for fun? Being like the part changing repair man that replaces parts until it works again? >>> 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. > > You can't set up your own cron.d. > Sure I can. Can't you? >> 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. > > I might know that a job already runs > and want to change the schedule. Or I just want to find out if something > is already scheduled but the time hasn't come for it to run yet. Or > worse, I want to tell someone on the other end of a phone line how to > make that change. > You want to change when a job runs, but you don't even know when it runs? Why? You keep talking about changing when jobs run without even knowing when it runs now, or why it runs when it does. Do you even know the name of the job you want to change, or the name of the package it comes from? If you are trying to change jobs without this information, then I can see why you get frustrated. Do you know if the job is run as root? A normal user? As a daemon user? Something about it? I guess if I was working in complete ignorance of the job I was trying to change, I would run "ls /etc/cron*" or "ls /etc/cron.*" and look at the file names. I can figure out that tmpwatch is going to have something to do with checking files or space in the /tmp directory just by the name. The fact that it is in cron.daily tells me that it runs once a day. I can even run "rpm -qf /etc/cron.daily/tmpwatch" and find out what package it comes from. If I am trying to figure out what files launch foo, I might do something like: for i in $(ls /etc/corn.*) ; do grep -l foo $i ; done If I suspect it is a user job, instead of a system job, then I would run "grep -l foo /var/spool/cron/*" instead. The command being run would probably give me a good indication of whether it is a system or user job running it. So would the user it is being run as. >> The scheme doesn't matter if you don't know when a job is run. > > Why would anyone know that? > Well, if you understand how something like log rotate works, you would know that it runs daily. If you get a calendar in your e-mail once a month, on the first of the month, you can kind of figure it is a monthly cron job. Little clues like that. And if you do not understand why it runs when it does, you should not be changing it. >> Changing when hourly, daily, etc jobs are run takes editing one >> file, and changing one time each. > > What if your daily job needs to be done twice daily? > Then it is not a daily job. A daily job runs one a day by definition. You will have to put it in cron.d instead, and figure out how to tell cron you want it to run twice a day, and at what times. Then again, if it needs to run twice a day, there may be specific times that would be best for it to run. They may not be 12 hours apart. It depends on the job. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
