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.)
|