--3MwIy2ne0vdjdPXF
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=
=20
>   | > 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 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=
 a=20
>   | different infrastructure?
>=20
> 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.
>=20
> 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.
>=20
> I think the simplest solution probably involves:
>=20
>     *	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.
>=20
>     *	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.=
=20
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=
=20
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.

Agreed.

Thoughts?

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAfElRWz+3JHUci9cRAjX7AJ4iOlktD2IKfHsKAmlecxpK8EUhPACferau
xr/PLD/SHGr13KBWXuMSkj4=
=cLU5
-----END PGP SIGNATURE-----

--3MwIy2ne0vdjdPXF--