Subject: Re: Implementing periodic.d
To: Julio M. Merino Vidal <>
From: Jim Bernard <>
List: tech-userlevel
Date: 04/05/2004 16:22:40
On Mon, Apr 05, 2004 at 11:10:28PM +0200, Julio M. Merino Vidal wrote:
> On Mon, 5 Apr 2004 14:44:14 -0600
> Jim Bernard <> 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.

  Yes, that's an issue.  It should be possible to have etcupdate help out,

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

  Yes, both config files must be modified.  It hasn't been a big annoyance,
but it would be nicer to have a single point of control.  It would be easy
to add a second argument to the run and skip functions that specifies the
frequency of execution:

  run msgs daily
  #run expire_news weekly
  run check_disks daily
  skip fsck monthly
  run rdist daily

Then all of the maintenance config files could be combined into one.  I
think I like that...