On Thu, Dec 15, 2005 at 08:48:04PM +0000, Stephen Gran wrote: > This one time, at band camp, Justin Pryzby said: > > On Thu, Dec 15, 2005 at 12:55:00PM +0000, Stephen Gran wrote: > > > > > > Probably the most portable way to handle it is to run the job from > > > cron.daily, but call a wrapper script that sleeps for a random amount of > > > time less than one day before runnign the actual job. For extra > > > goodness, use a lock file so that if the last random sleep was 23 hours > > > and 59 minutes, and the next one is 1 minute, you don't two jobs at > > > once. > > But that means essentially running a daemon for the package, > > completely undermining the point of cron. > > Except that it doesn't fork to the background, close file descriptors, > or handle requests. Basically it would do > > sleep $RANDOM > touch lock.tmp > if ln lock.tmp lock 2>/dev/null; then > rm -f lock.tmp > run program > rm -f lock > else > rm -f lock.tmp > fi > > Not much a daemon, if you ask me (unless your definition of daemon is > anything that uses a timer and sleep). Its a thing that I see in `ps aux` about which I shouldn't need to worry => daemon :)
Seriously, though; Device And Extension MONitor. Okay, so its only interfacing with the clock, and indirectly and passively at that. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
