As an aside, we are writing our frames to a temp locally, then copying
them. One of our td's ran quite a few tests and determined that the
network load was significantly higher (and ultimately slower) with
network only renders. Rendering locally and then a cp /tmp/finishedframe
-> /net/finishedframe reduced the load and improved throughput a lot.
I think we still drop a 'touch' tmp file to the net destination to let
the render manager know the frame is being worked on, which as a bonus
concerning your issue, puts the control of it's cleanup back in our hands.
JRAB
On 9/14/15 10:20 PM, Jake Richards wrote:
Hello:
We are using Nuke 8 in linux and I'm noticing a lot of .tmp files
being left behind on jobs that get interrupted. So, say Nuke is
rendering and a higher priority job comes along and sends a SIGINT to
it, nuke quits but leaves behind the .tmp file it was writing. On
shows that used version 7 I don't really see any of these .tmp files.
Was there something changed in the way Nuke handles
interrupts/signals? Is there a better signal to send to Nuke to have
it quit more gracefully and delete the .tmp file it was working on?
Unfortunately, we can't use Nuke 9 just yet, so hopefully looking for
a solution for Nuke 8 that also won't have me writing a script to
clean out the .tmp files when a job is done.
Or, can I maybe tell nuke to write to a temp space and then move the
finished frame to the network?
Thanks!
Jake
--
--
--------------------------------------------
tru...@blueskystudios.com 203-992-6319
LTD Blue Sky Studios
--------------------------------------------
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
