On Wed, Apr 16, 2008 at 12:41:35AM +0100, Miguel Lopes Santos Ramos wrote:
> I just noticed that scripts in /etc/daily.local, /etc/weekly.local, etc,
> never run.
> The reason seems to be that the /etc/periodic/daily/999.local and similar
> scripts use "for script in $daily_local". Because the variable
$daily_local
> is initialized in /etc/defaults/periodic.conf to /etc/daily.local, which
> actually does not contain a wildcard, the for loop step executes only once
> with the variable script bound to "/etc/daily.local". There's
no iteration
> over scripts contained in /etc/daily.local.
/etc/daily.local was never supposed to be a directory, it always was a file
from very early ages. I still use it this way :-)
> I have no idea when this might have gotten broken. The 999.local scripts
> date back to 2001. It's curious that no one has noticed.
> Perhaps most people just use the crontab or put their scripts directly into
> /etc/periodic/daily, etc.
/usr/local/etc/periodic/daily should be used for own periodic jobs.
> Anyway, scheduling things in crontabs and the like is not very good when
> the system is not always on.
> Since UNIX is no longer such a "time sharing system" and many
people run
> desktops and part-time servers, wouldn't it be desirable to have a
periodic
> job scheduling mechanism that would reliably run jobs when a given amount
> of time (uptime or not) had passed?
I just include a line at start of script job:
echo "$0" "$@" | at 6:00 tomorrow
So, this script will be called next day, 6:00 or,
if desktop'll be turned on later in the morning,
the job runs just after boot. "At" scheduler will take care of the
rest:
current directory for job and environment, it keeps them safe.
Eugene Grosbein