Subject: Re: Implementing periodic.d
To: Luke Mewburn <lukem@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 04/13/2004 13:10:57
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 13, 2004 at 09:52:35AM +1000, Luke Mewburn wrote:
> On Mon, Apr 12, 2004 at 01:46:11PM -0700, Bill Studenmund wrote:
> | On Sat, Apr 03, 2004 at 11:17:24AM +0200, Julio M. Merino Vidal wrote:
> | > Hi all,
> | >=20
> | > Looking at misc/14825, found a minor discussion about creating=20
> | > /etc/periodic.d, which is very interesting. Some of the people who=
> | > replied to it said that they were working on implementing this, but=
> | > last message in the PR is dated as 2002, so it seems nobody finishe=
> | > right? ;)
> | I've been following this thread off & on.
> | We already have cron which runs things at given times. Why do we need=
> | different infrastructure?
> Because the way that /etc/daily, /etc/weekly, and /etc/monthly
> currently operate is suboptimal. For example, it's currently
> difficult to configure the weekly.conf(5) rebuild_locatedb to
> run on a daily basis.
> At least, that's my personal motivation for wanting this stuff
> cleaned up. I've been lurking on this discussion to see how the
> various ideas pan out before getting too involved.
The thrust of my question, though, was why not soup up cron to do this?=20
I'm asking it as I have a feeling this discussion is wrapped up in our=20
existing scripts and may do well to look outside the box, so to speak.
Note, I'm championing this idea more to get folks to think about it than=20
to say we MUST do it. If we don't do it, that's ok.
> Almost all of the periodic operations are independant, and it
> shouldn't really matter what order they run, except that end
> users probably want some consistency in output between runs.
> Because of this, I'm not (yet) convinced that we need rcorder(8)
> to order the operations for each periodic status.
> I think the simplest solution probably involves:
> * Put each of the operations into separate periodic.d scripts.
That sounds good. /etc/periodic or /etc/periodic.d?
> * /etc/daily loads /etc/daily.conf and only runs the
> periodic.d scripts (in alphabetical order?) that have
> been enabled in the latter.
> All periodic operations are available if necessary.
> * Same goes for /etc/weekly and /etc/monthly.
One issue that was pointed out to me about cron is that you have to have=20
one big cron file, and auto removing and auto updating aren't so easy.
So how about this for an idea. Rather than daily.conf, weekly.conf, etc.,
why not add files to /etc/periodic.d (or whereever the scripts are) that
indicate when it should run? Make them crontab fragments. Have them take
the name scheme: foo and foo.cron.
Taking rebuild_locatedb as an example. We'd have=20
/etc/rebuild.d/rebuild_locatedb and /etc/rebuild.d/rebuild_locatedb.cron.=
The former is the script, and the latter would contain when the script=20
The .cron lines would be just like crontab entries, except the command=20
(well /bin/sh /etc/periodic.d/foo) would be implicit. Anything where the=20
command would normally be would be taken as command arguements or building=
up a pipe.
All cron would need to do is learn to turn /etc/periodic.d/*cron files=20
into crontab entries for the respective files.
I like the idea ( :-) ) for a few reasons. 1) We don't stack different=20
layers of abstraction on doing a periodic task (cron then something=20
rc.conf-like). 2) It's easy to modularize. Just add a periodic.d/ script=20
and .cron file, and your task runs every-so-often. 3) We have a lot of=20
flex about when something runs. Want it to run tuesday and thursday=20
nights? No problem. /etc/daily and /etc/weekly don't do that so well...
> I probably wouldn't use the run_rc_command() infrastructure because
> we want to be able to run periodic operations without having to
> use "periodic.d/somescript forcestart", and I'd rather _NOT_ use
> more trickery to work around this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----