Subject: Re: Implementing periodic.d
To: Simon J. Gerraty <sjg@crufty.net>
From: mouss <usebsd@free.fr>
List: tech-userlevel
Date: 04/07/2004 01:15:56
Simon J. Gerraty wrote:


> Personally I don't think rcorder is a suitable approach for this.

while rcorder has benefits, it has some problems:
- it's too magical. the "distance" between what you do and what is done 
is large. so it's not simple to control the execution.
- it's too flexible. This might be seen as an advantage, but too much 
flexibility is generally not good (the system is not optimized for 
general use, it's optimized for "any" use).
- there is no point in putting the config layer in an rc.conf file. why 
not then have the order in a config file?
- there is constant processing. an alternative is to provide a tool to 
generate "something" that works without the need to call rcorder 
everytime (at worst, a caching system may be used).
....

> As you note, you end up needing lots of .conf files that need 
> coordination which seems to negate much of the benefit of using
> individual scriptlets.
> 
> I found it quite adequate to use the convention that foo.sh get's sourced 
> by the rc script and foo gets run as a child, this ends up being more modular
> and easier to re-use bits.  Eg. I use many of the same foo.sh's in rc_local.d 
> and {hourly,dail,...}.d 
> 
> I also found simple numeric odering adequate - but that seems to irk
> many - too low tech I guess ;-)

the problem with numeric files is that at start you have 10.foo and 
20.bar, then you add an intermediary 15.blop, then 13.meuh, then 
11.blop, then you wanna add a script between 10.* and 11.* and then you 
got a problem.

one thing is that you don't always need ordering. some tasks may depend 
on others of course, but this doesn't justify simplifying the problem by 
requiring a full ordering scheme. A simple model is using stages (this 
somewhat resembles the old sysv init states, but doesn't have the 
problem of a 0-6 magical numbers) which would then model the ordering 
reqs, and inside stages have unordered tasks. the corresponding graph is 
so simple you can easily see what is being done, and on the other hand, 
makes life easy for those who wanna create a gui.