On Sun, Apr 25, 2004 at 11:44:39PM +0200, Julio M. Merino Vidal wrote:
> 
> Consider the following /etc/defaults/periodic.conf:
> 
> task1=daily
> task1_step=1000
> task2=daily
> task2_step=2000
> task3=daily
> task3_step=3000
> task4=weekly
> task4_step=1000
> ..
> 
> And so on.  /etc/periodic.conf simply overrides taskN style variables to
> change the periodicity of when they are executed, and/or changes taskN_step
> variables to modify the order in which tasks are executed.
> 
> Then, you'd do this from cron:
> 
> run-parts -c /etc/periodic.conf -s daily /etc/periodic.d
> 
> I think the advantages of this are:
> 
> - A single configuration file to tune when tasks are executed and the order
>   between them.

  I like this.

> - No need to mess with file names to change the order of tasks.  And the
>   order is very concrete, not like rcorder (which most of you disliked).

  I like this.

> - A generic script to run the scripts that could be used in other places.

  This too.

> Comments?

  But I'd much rather not have to specify sequence numbers for the tasks
(and I'm not fond of the resulting clutter).  It means you have to examine
the sequence numbers carefully to determine the actual sequence of tasks,
rather than having it presented to you in some obvious way by the layout
of the file(s).  And you have to specify sequence numbers for all of the
tasks, even though the sequence doesn't matter for most of them.  Further,
if you change a task from daily to weekly (e.g.), a completely new set of
sequence numbers becomes relevant to it.  Switching back and forth (for
those who have trouble making up their minds) then becomes burdensome.

  Now doing away with the sequence numbers seems to make it difficult to
have system (default) updates automatically add new tasks without the need
for user intervention, since it would seem to imply that the actual sequence
of tasks must be specified by the order of lines in a single file, which
would have to be the local conf file if the user wants to make any changes
from the default.  I see a few options to address this, none of them without
fault:

  1 Use rcorder.  This makes the sequencing more difficult to discover,
    but it's easy to get interdependent tasks in the right order.  It also
    makes it necessary to modify existing scripts (or copies thereof) to
    make changes in the sequencing.  Since the order doesn't really matter
    in most cases, this is overkill.  But for the same reason, maybe it
    doesn't matter much if it's hard to discover the order and hard to
    change the default order.

  2 Live with the fact that the user has to copy the entire defaults file
    in order to make changes, and the local conf file won't be automatically
    updated if there are new tasks added to the defaults file.  etcupdate
    can help with this, but it's still an annoying issue.

  3 Add a configuration tool that would present the user with lines whose
    sequence represents the execution sequence, but that translates any
    user changes into some appropriate set of local conf-file bits in
    whatever format is chosen.  The underlying implementation then becomes
    unimportant (sequence numbers would be OK) and is free to change later.
    But it adds another layer that removes the user from what's really going
    on, and adds complexity and opportunity for failure due to bugs in the
    config tool.

  4 Have the super script (run-parts or whatever) merge the lists of tasks,
    so that any that appear in the local conf file cause deactivation of
    any specifications in the defaults file.  This way, new tasks that
    show up in the defaults file will be run automatically.  To give the
    user some control over sequencing, here are some possibilities:

      a Make the local conf file have "before" and "after" sections, whose
        tasks are entirely executed before and after the tasks in the defaults
        file.  If the sequence of tasks in the defaults file needs to be
        changed beyond movement of a single task to the before or after
        sections, or a local task needs to be inserted between two tasks in
        the defaults file, it could be necessary to copy a substantial chunk
        of the defaults file to the local conf file.

      b Provide "before" and "after" keywords to allow arbitrary insertion
        by the user.  In the absence of those, the tasks would be run in
        script order, as determined by some merger of the defaults file and
        the local conf file.  E.g.,

          run task3 weekly
          run task1 daily before task5
          run task6 daily after task2

        This is somewhat like using rcorder, but control over the sequencing
        is moved to the conf file, so that changes to the default sequencing
        don't require changes to the scripts.  And in most cases the sequence
        is simply that given in the merged conf file(s), with no need to
        specify it explicitly by keyword.  But the ordering can become less
        visually obvious than with a strictly line-ordered sequence, and it
        is possible to specify inconsistent ordering requirements.  This one
        could also include 4a.

      c For those few tasks for which sequencing is important, combine the
        scripts into a single script or use a wrapper script, rather than
        the individual scripts to run them.  In most such cases, it would be
        necessary to keep them together anyway, in the sense that changing
        one of them from daily to weekly (e.g.) would require changing them
        all and keeping the same order.  But this does reduce flexibility.
        This one could usefully include 4a.

  5 Attach the sequence numbers to the names of the scripts (or links to
    the scripts), letting the config file merely specify what is to run and
    how frequently.  This has most of the disadvantages of having the sequence
    numbers in the config files, though they'll be automatically presented
    in order by ls.

  I would lean toward 4b or 2, and I could live with 4a, 4c, or 1.  I don't
like sequence numbers in any form, including 5, and I'd much prefer to
avoid the need to use a config tool (3), beyond a simple text editor.

--Jim