cron

[Mikkel L. Ellertson]

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!