Subject: Re: Implementing periodic.d
To: Luke Mewburn <>
From: Bill Studenmund <>
List: tech-userlevel
Date: 04/13/2004 13:10:57
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
d it,
>   | > right? ;)
>   |=20
>   | I've been following this thread off & on.
>   |=20
>   | 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
should run.

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.



Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)