on Fri, Apr 27, 2001 at 10:18:58AM -0500, Dave Sherohman (esper@sherohman.org) wrote: > On Fri, Apr 27, 2001 at 01:20:00AM -0400, Dan Christensen wrote: > > Does anyone have any clever solutions to the following problem of a > > similar nature: I want to run a job at 28 day intervals, i.e. on > > every fourth Sunday. > > Not terribly clever, but just end your script with > > echo '/path/to/script' | at now + 28 days > > and then run it manually (or from a manually-scheduled at job) on a Sunday. > It will repeat itself every 28 days. In theory, theory and practice are the same. In practice, they differ. Two problems: An 'at' job doesn't run _when_ scheduled, but _after_ it's scheduled. On a lightly-loaded system, this may not appear for some time, as slips of less than a minute are rounded (well, floor()'ed), to the current minut. On a heavily-loaded system, time-creep may be significant, particularly if the 'at' queue doesn't submit jobs when system load exceeds certain levels. Useful for using scheduling to even system load, harmful when trying to be punctual and predictable. You're creating a job chain. The chain only works if it runs. The problem is when it doesn't run, in which case the n+1th iteration isn't scheduled. In this case, you need to schedule _another_ job to check for evidence that the first job has run. The easy method would probably be to have a (depending on the time-criticality of the job) daily or weekly job to look for some artifact(s) left by the periodic job. A better solution, once you get to this level of complexity, is a true job-management solution which includes robust, guaranteed, scheduling, notification, and more flexible execution options than are available with cron and at. This is where mainframe programmers usually start gloating over Unix / GNU/Linux freaks, but truth is there are some robust scheduling apps for 'nix as well. > Unfortunately, cron is not suited to scheduling tasks on criteria > other than what the date itself looks like. Something like this > requires knowledge of when the job last ran and cron doesn't know > that. Agreed. > You could also do it based off the week of the year, obtained from > date %U, %V, %w, or %W, but that could result in non-28-day intervals > at the end of the year. At this point, it's time to consult business rules and determine what the requirements of the job are. If it's to run the job at 28 day intervals, find some way to do that. If it's to run the job on the 28th day of the year, and every 28 days following, resetting on the year, then you've got another possible solution. Interesting discussion. -- Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
Attachment:
pgph1tY2GZT6z.pgp
Description: PGP signature