Jonathan Thornburg wrote: > ... > Some of the /etc/weekly stuff (eg rebuilding locatedb) involves > walking all (non-NFS) mounted filesystems, so it really eats disk > seek bandwidth, i.e., it makes the machine painfully slow for most > other use while it's running. So, only a human can decide when a > good "quiet" time is to run the disk-cruncher. No automatic scheme > can avoid being at a bad time occasionally for some users.
+1 there's no one single 'right' time that will fit all users or, even for a single user, all situations. > So, what's needed is a cron with flexible-enough specification > semantics (a.k.a. "crontab on steroids") so a human can tell cron > what the ok-to-run times are. I'd look in the direction of the update scripts if adding complexity. The scripts are wrappers for a laundry list of maintenance activities. Some of the activities don't take that long unless they have to fight with other activities for system resources. The only one that's given me trouble is the one mentioned above, rebuilding locatedb. Having the script take a turkey look using vmstat or iostat to see if load is below a certain threshold. If the load is to high, then it can use at, to reschedule that part of the daily. For that to be practical, the components of daily and weekly scripts would need to be set as subroutines so that maintenance activities can be re-called separately using 'at'. /Lars Nooden
