Subject: Re: Implementing periodic.d
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-userlevel
Date: 04/04/2004 14:57:31
[ On Sunday, April 4, 2004 at 04:13:34 (+0000), John Hawkinson wrote: ]
> Subject: Re: Implementing periodic.d
> With something like periodic.d, I would expect that it's more important
> for the user to see the big picture than it is to be able to have programs
> automatically insert events such that they are relative to other events.

I agree with that 101%.

I'm also rather stunned by jmmv's apparent lack of interest in examining
existing practices (outside of NetBSD) before plowing on with something
apparently invented practically in isolation and without at least asking
those who've used the other similar systems about their experiences,
good and bad.  It's a simple fact these days the the majority of
experienced systems administrators don't use NetBSD, and ignoring their
experience doesn't seem wise, especially when attempting to devise a new
solution to an age-old problem that all types of systems face and when
other "new" solutions to these problems have been introduced in other
similar systems.

I have come to agree that using filenames or symlinks to set the order
of execution is not a good idea.  However I don't like rcorder (as it is
implemented) that much either though, especially for this purpose.  I
think there are much better ways of doing this generic task which don't
require changing the scripts files themselves in order to change the
order of execution, and which are much easier to do change management on
than (sym)links in a directory.

Some combination of rcorder (to error-check any actual dependencies the
script authors know for certain, but not to trigger execution) with a
simple list of programs in their desired order of execution (per period)
is probably the most ideal solution, though even just the ordered lists
is better than (sym)links or rcorder alone.  Note the use of ordered
lists would preclude the use of boolean YES/NO flag variables -- a
procedure would be enabled simply by including its filename in a list.
The lists could be separate files, or just separate tokens in shell
variable setting.

						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>