cron

[Mikkel L. Ellertson]

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!