Subject: Re: Another approach for periodic.d
To: Julio M. Merino Vidal <firstname.lastname@example.org>
From: Jim Bernard <email@example.com>
Date: 04/27/2004 09:15:09
On Sun, Apr 25, 2004 at 11:44:39PM +0200, Julio M. Merino Vidal wrote:
> Consider the following /etc/defaults/periodic.conf:
> 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.
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
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
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.