cron

[Les Mikesell]

Mikkel L. Ellertson wrote:

>>> 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.

The ones that were inherited from older systems usually had functional 
reasons.  The moves and renames since have mostly been arbitrary.

> After all, do we really need /bin, /usr/bin,
> /usr/X11R6/bin, and /usr/local/bin? 

The X stuff is the only oddball there and it can easily be a symlink to 
/usr/bin.  /bin must be on the root filesystem because it contains 
programs needed by the boot processes. /usr/bin can be mounted later. 
/usr/local/bin is obviously for locally  added things, not part of the 
distribution.  On the other hand, there is nothing functionally 
different or necessary about /sbin and /usr/sbin vs. their counterparts. 
  If you want to control who can execute something you can do it with 
permissions instead of obscure paths.

> We could put all the programs we
> want users to be able to run by default in /bin.

In these days of big drives, you could.  But /usr/local/ still needs to 
be separate to avoid conflicts with same-named system programs that 
might overwrite the ones you need in an update.

 > You may want to
> read the Linux-Filesystem-Hierarchy some time. It is full of
> arbitrary locations for things.

No, it's too depressing.  Every time that committee meets I have to go 
re-write dozens of scripts that would otherwise have run unchanged for 
decades.

 > 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.

>> 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?

No.

> 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.

> What
> next, complaining because root's home directory is not in /home like
> the user's home directories?

No, that has the same functional reason as the separation of /bin and 
/usr/bin.  The root user must be able to work in single user mode before 
any partitions have been mounted.  /home is better off on a mounted 
partition.  And, there is no issue with finding the location of any 
particular home directory since they are all identified in the 
/etc/passwd file and the shell will interpret ~username as that path for 
you.

> 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.)

I'll look at that when they stop changing it with every version and/or 
they come up with a scheme that interoperates with with non-linux 
systems - or even older versions of their own schemes.


>>> 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.

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?

>>> 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?

They might be wrong.  They might conflict with something else I have 
running.  Or I might want to make my own arbitrary changes.

> 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.

>> 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?

 > 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.

That's not what I'm suggesting, although if the underlying structure is 
not all hard-coded arbitrary special cases it becomes much easier to 
wrap it with an understandable interface.

 > For some things,
> you have to be willing to learn enough to make informed choices,
> accept the defaults,

And change them every time a committee votes...

> or get someone that has the knowledge to make
> the changes for you. 

Again...

-- 
   Les Mikesell
    lesmikesell at gmail.com