Subject: Re: Implementing periodic.d
To: None <tech-userlevel@NetBSD.org>
From: Luke Mewburn <lukem@NetBSD.org>
List: tech-userlevel
Date: 04/13/2004 09:52:35
--Rsp728Nwk8twChKq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 t=
he
  | > last message in the PR is dated as 2002, so it seems nobody finished =
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?

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.

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.

    *	/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.

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.


Cheers,
Luke.

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

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

iD8DBQFAeyvDpBhtmn8zJHIRAh/CAJ9eTeStQaeNO8tVrRJM6vU2j2z9YQCcDBGK
3r/gB3pgmqXgqx09fD1MCfk=
=5br/
-----END PGP SIGNATURE-----

--Rsp728Nwk8twChKq--