Re: [johannes@caldera.de: Comments on Chapter 17 (cron) of the LSB Spec]

[Thorsten Kukuk <kukuk@suse.de>]

[...]

> 
> 1 It is desirable to control the order of execution of the scripts
>   put in one of the "periodic scripts directories" ( /etc/cron.daily etc.).
> 
>   This can be done by adapting the naming scheme inside /etc/init.d,
>   using two digit prefixes, which control the order of execution.

When does cron jobs depend on each other ? I don't know any case in the
moment. And if they depend on each other, I would put it in the same file.
A simple solution without big overhead.


> 2 It should be possible to move the scripts from one "periodic scripts dir."
>   to one other, to control frequency of execution.

I think in the most cases there are good reasons why a script runs at the
default frequrency.

> 
> 3. Both requirements 1. and 2. make it difficult for package managers to
>    cleanly remove or update because the script names and path can change.
> 

This is true.

> 4. This is why Caldera uses a common cron script repository 
>    (/etc/cron.d/lib in OpenLinux 2.4) and uses soft links to these
>    repository from the periodic scripts directories. (modeled
>    after /etc/init.d/) The soft links must be named XXname, where
>    XX is 2 digits and name is the name of the script pointed to.
> 
>    Example: /etc/cron.d/Daily/40cleandir ->../lib/cleandir
> 
>    The local system administrator now can rename and move these
>    soft links inside the periodic scripts directories, but the
>    package manager can get the information which soft links point
>    to which script. As the scripts are part of a package, the
>    package manager could completely control these soft links.

I think this is too much overhead for cases you normally never will
run into. Now you can make a lot of more mistakes and search for
errors for nearly no benefit.

>  
> 5. /etc Name space pollution
> 
>    The actual proposal enforces 5 cron related directories in /etc.
>    (Or even 6 if our cron script repository idea is used). This can
>    get even worse, if somebody wishes more periodic scripts directories,
>    say /etc/cron.biweekly.
> 
>    This is why we propose to keep the historical place /etc/cron.d/
>    and put the following directories inside:

I have no problem with a /etc/cron.d, sounds like a really nice idea.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.