After last week's discussion here, Carrie and I have thought a bit
about this.

Definitions:

meta-job: A collection of things that need to be run together. For
          example, the stuff currently in /etc/daily.

sub-job:  A small, hopefully distinct, piece of a meta-job, such as
          "cleaning old files in /tmp."

script:   Any executable that will run a sub-job. Typically an
          executable piece of shell-script.


Objectives:

1. Configurability. It needs to be easy to change the order of the
   sub-jobs that make up a meta-job. Also, it should be easy to create
   additional meta-jobs besides the system-provided daily, weekly, and
   monthly ones. Ideally, this system should be configurable enough
   that daily.conf, etc. are no longer needed. Also, it should be
   possible to disable a sub-job without removing a file or changing a
   file's name.

2. Intuitiveness. Whatever that means, in the context of Unix. Once
   the user understands the basic premises of the system, it shouldn't
   be necessary to read the man page to access basic functionality.

3. Scheduling. The sub-jobs that make up a meta-job need to run in
   order, one at a time, and not simultaneously. This could also be
   seen as the requirement, the reason we don't just use cron.

4. Extensibility. It should be easy for, e.g., a package installation,
   to add a sub-job to the daily, weekly, or monthly meta-jobs. Think
   INN here, or whatever other package you prefer.


Plan:

There should be a directory, /etc/periodic.d or similar, that contains
a global config file (periodic.conf), and sub-directories for each of
the meta-jobs that are available. In each sub-directory (e.g.,
/etc/periodic.d/daily), there should be scripts to represent the
various pieces of the job, and also a config file that's specific to
this meta-job. The meta-job-specific config file would, of course,
override any defaults specified in the global config file.

By default, the scripts in the meta-job's directory would be run in
lexicographic order, but this would be overridable in the config
files.

The config files would act on sub-job script names based on
shell-style globbing. For instance, I could put a directive in the
global config file that would say, "Run scripts named inn.* last." Or,
"Disable pgsql.* scripts."

I'm not at all certain what syntax the config files should have, but
here's a first shot:

* Comments begin with #, of course.

* "priority <n> <pat>" means to change the priority of any scripts
  matching <pat> (shell-style globbing) to <n> from the default of
  0. As with CPU priorities, negative numbers are more
  important. Range is -20 to 20. (Is that limitation necessary?)

* "disable <pat>" means to disable (not run) any script matching
  <pat>, regardless of what priority has been specified for
  it. Overrides any previous "enable" statements.

* "enable <pat>" means to enable (run) any script matching <pat>,
  overriding previous "disable" statements.

The default state of any job would be enabled, with a priority of 0.

Thoughts?

Chris

-- 
-----------------------------------------------------chris@cjones.org
Chris Jones                                          cjones@honors.montana.edu
           Mad scientist at large
"Is this going to be a stand-up programming session, sir, or another bug hunt?"