I can confirm that the close () command has fixed the issue, haven't had a problem since.
Awesome work once again Greg!
Thank you
Craig
Craig Allison
Digital Systems & I/O Manager
The Senate Visual Effects
Twickenham Film Studios
St. Margarets
Middlesex
TW1 2AW
+44208 607 8866
craigallison@(email surpressed)
skype: craig_9000
On 17 Feb 2011, at 20:33, Greg Ercolano wrote:
> [posted to rush.general]
>
> Craig has followed up with me offline on this; seems it might just be
> a small omission in script he's working with.
>
> The script writes out a shake file then submits a shake job to render it.
>
> The problem just might be an issue of a missing close() in the script;
> after writing the shake file it submits the job. But without the close(),
> if the job picks up quickly, shake will see an empty file, and finishes
> immediately with the frame "Done".
>
> The intermittent behavior seems due to how quickly the job picks up;
> if it picks up quickly, shake sees an empty file. But if it takes
> an extra second or two to pick up, the submit script finishes executing,
> automatically closing the file, flushing it to disk.. then when the job
> kicks in, shake reads the proper file.
>
> This would also explain why re-que'ing the frame always renders successfully.
>
> Adding a close() to the custom script will likely fix the problem.
> Otherwise, if there's still trouble, I'd suggest experimenting with sync(1)
> and/or fsync(2) to ensure the OS commits the file to the remote server before
> continuing. (But that really shouldn't be necessary.)
>
|