Subject: Implementing periodic.d
To: None <tech-userlevel@NetBSD.org>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
Date: 04/03/2004 11:17:24
Looking at misc/14825, found a minor discussion about creating /etc/periodic.d,
which is very interesting. Some of the people who replied to it said that they
were working on implementing this, but the last message in the PR is dated as
2002, so it seems nobody finished it, right? ;)
The main idea is to create an /etc/periodic.d directory where several scripts
reside (as /etc/rc.d), each one doing a single task. Then, have the daily (and
other scripts) parse daily.conf and such files to get several yes/no values,
use rcorder to sort the periodic.d files accordingly and run the ones which
had their setting set to yes.
So I started to work on it, and already got a preliminar working version. Even
though, there are several "design" questions that I would like to expose to get
some discussion about them...
As they are now, the scripts use rc.subr to get basic functions like
checkyesno. The new scripts should be similar to what we have in rc.d, so
I tried to use other rc.subr functions to handle them. Although they work,
they are not intuitive, and provide lots of functionality that won't be
used. For example, a periodic.d script should not get any 'start|stop'
arguments, as they will only confuse people.
So I added a periodic.subr file, which contains some simple functions (but
very similar to the ones in rc.subr, like load_periodic_config,
run_periodic_command, etc) to get them working. I hope there will be no
"problem" with this.
2) Configuration files
We now have three configuration files to tune what happens in the scripts.
These files set several variables to yes/no to determine what needs to be
executed. The "problem" here is that, with the new framework, if somebody
wants to add a new script in periodic.d, has to modify three files to
reflect this change (set it to 'yes' in one, and 'no' in the others). If
he doesn't do it, then he'll get warnings at runtime about an undefined
The other approach I see is to have a single periodic.conf file where each
variable can take any of the following values: never, daily, weekly or
monthly. This way, only one file needs to be modified, and a job will be
always executed from a single script.
I prefer the later option, as it's clearer and more centralized, but breaks
3) The scripts themselves
After the changes, /etc/daily and others become a 5 line script, which aside
of setting some variables, call a start_periodic function with an argument
that specifies the frequency, i.e., 'daily'.
I think they could be merged into a single script, say /etc/periodic, that
directly takes the argument from the command line. So one could run
'/etc/periodic daily' and get what's expected. Doing this will mean a
minor change in root's crontab to call the new script.
I also prefer the later, but breaks even more with "tradition"...
The security script is conceptually different than daily, weekly and monthly,
but as it's directly handled by them, it could be treated the same. That is,
if we go with a single configuration file for all the scripts, add a fifth
Is it a good idea to implement this? Comments on the specific details?
Julio M. Merino Vidal <email@example.com>
The NetBSD Project - http://www.NetBSD.org/