Yes, communicating state can be problematic for timed jobs. The solution I hit upon was to have the file preparation job rename the file as a last step. I was culling records from a log and the final step was to rename the file with cull in the name.
The cronjob wakes and attempts to pick up the file. If that name did not exist--no 'cull' in the filename--I would bring back a listing and email it as an error. This provided information regarding the state on the remote machine. If no filename existed whatsoever, wow, the job wasn't able to write to disk, eh? If the filename existed sans 'cull', the job abended, took too long, and so on. good luck! --- [EMAIL PROTECTED] wrote: > On Tue, May 21, 2002 at 11:42:43AM -0500, shawn > merdinger wrote: > > hmmm....a simple cron job ith ssh should be able > to handle this...maybe > > run it every cople of minutes. > > The only problem with running a job like that in > cron is you don't know > how long it will take , so either you set the jobs > far apart (so they > won't step on each other, and take longer than they > would have otherwise, > which could result in having a lot of synsc runing > at the same time), > or you set them close together (to prevent a large > lag time between > the servers). If you do this from cron, you should > have some way of > making sure the last job isn't still running. You > can always set it > up as a daemon, which goes in an infinite loop until > its told to stop, > and has a wait of a few minutes before starting a > new sync. > > > > Rob > > ATTACHMENT part 2 application/pgp-signature __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
