[...] > > 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/ [EMAIL PROTECTED] 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.
