Subject: Re: Implementing periodic.d
To: Jim Bernard <jbernard@mines.edu>
From: Julio M. Merino Vidal <jmmv@menta.net>
List: tech-userlevel
Date: 04/05/2004 23:10:28
On Mon, 5 Apr 2004 14:44:14 -0600
Jim Bernard <jbernard@mines.edu> wrote:

>   I'd like to describe some features of a scheme I've been using
> happily for almost 7 years on a couple of systems, since they may be
> of some interest to you or to others.  I split the daily, weekly,
> monthly, and security scripts into separate task scripts that live
> in /etc/maintenance/{daily,weekly,monthly,security}, and I added the
> directories /etc/maintenance/{local,security.local} for local additions.
> There's a utility script that contains some minor functions used in the
> task scripts and two "user" functions, called "run" and "skip".  Then,
> /etc/daily, e.g., does a little job-specific initialization, processes
> the utility script, processes /etc/daily.conf if it's present, cleans
> up, and exits.  If daily.conf is absent, daily has a default list of
> tasks that it runs, and that list serves as a handy template for
> initializing a conf file.  The conf file, which is just a shell
> script, can contain commands like:
> 
>   run msgs
>   #run expire_news
>   run check_disks
>   skip fsck
>   run rdist

I thought about something similar, but in a single file.  I.e., have a script
with three shell functions, daily(), weekly() and monthly() that just contain
calls to what you want executed, in the exact order you want.

The disadvantadge of this (or not, depending on how you look at it) is that
you can't have a 'defaults' file.  Or if you do, whenever you want to modify
the default settings, you have to duplicate the entire function into the
local configuration file to make the changes.  Not having a defaults file is
bad, IMHO, because if some new job is added to the system (and you don't
notice it), it won't get executed.

And in your approach, to move a job from daily to weekly, for example, you
have to modify two files; isn't it?

Thanks for your comments!

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/