>There seems to be a number of issues with /etc/{daily,weekly,monthly}.
>
>misc/14825: asks for all the scripts to be unified, so that (for
>example) setting rebuild_locatedb=YES in daily.conf would cause
>the locatedb to be rebuild daily, rather than weekly. Greg Woods
>then suggested that our whole framework should be replaced by
>something like FreeBSD's periodic(8).

that's being looked at, but isn't a terribly pressing task, i'm
afraid.

>misc/11011: points out that when bringing a laptop up from several
>days or more of bieng suspended, the daily/weekly scripts immediately
>kick in and start several very battery-expensive operations (i.e.
>find / ...). John Hawkinson replied, suggesting that the multiple
>find / operations could probably be eliminated, and mentioned some
>other problems with daily/weekly scripts on laptops.

ooh!  we already fixed that.  months ago, too.  no idea there was a
pr.  i'll close it.
 
>Several other open PR's ask for tweaks or extra options. See: 
>bin/17029, bin/20272, bin/22148, bin/22230, misc/7716, misc/11046
>misc/17306, misc/18628.

okay, let's see...

17029	interesting idea
20272	again, interesting idea
22148	hmm...this is only tangentially related
22230	ah, good point
7716	this goes back to solving the tricky find problem
11046	another reason to make things a bit more modular
17306	arguable
18628	another good point

>*My* beef with the current setup is this: I shut down my PC when I'm
>not at home (most of the day) and asleep (a depressingly small
>fraction of the night). As I do, however, usually make it to bed
>before 3AM, /etc/{daily,weekly} never run.

you are a good boy.  i'm frequently still up at that point.  :)

>I've looked at FreeBSD's periodic(8), and it's rather more modular
>and extensible than our framework. It does not, however, solve the
>problem that I'm referring to. Slackware Linux does something
>similar to FreeBSD, just not quite as well.
>
>The two solutions that I've seen are anacron (anacron.sf.net) and
>a limited bash-script clone of anacron in Gentoo Linux. Basically,
>for each periodic job, a timestamp is kept under /var. Several times
>an hour, a script is run that checks the age of each timestamp
>relative to the period of the corresponding job.

that's interesting, but i suspect it would end up irritating more
people that it helped.  speaking for myself, i don't want a job
kicking off in the middle of me doing something just because its
gotten fed up with not being allowed to run for too long.

>Basically, the problem has irritated me to the point that I want
>to fix it. I figure I may as well fix other people's problems at
>the same time. I also realize that many NetBSD systems _are_ 
>AC powered and up 24/7, so very little of this applies to them.
>
>Is there any consensus as to what would be required/unacceptable
>in a new periodic implementation? I have lots of ideas and some
>running code, but I want to get some input on this before I go
>any further.

modular would be good.  being able to use the old config files as well
as a new one (that listed when everything was to be run) would be
good, too.  another aspect of modular would be the ability to run an
arbitrary piece of it at any time (for example, sometimes i want to
update my locate database in the middle of the afternoon because i'm
fed up with all those erroneous results from stuff i know i just
deleted).

these are some of the ideas i've archived in the back of my head.

unless you're dead set against it, perhaps you might want to set up
daily to run out of cron @reboot as well?  or instead?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."