tail lets me see the output of the nuke render command itself in real time
from my NFS mounts.
Our current Nuke submit is written in Perl; is there a Python version already,
or are you recommending that we try to write our own from scratch?
On Oct 26, 2010, at 7:20 PM, Greg Ercolano wrote:
[posted to rush.general]
> Daniel Browne wrote:
> > I'm sure Dan Rosen's inquired about this before, but has anyone found a resolution
> > to the issue of the nuke frame log not updating until the render is
> > complete? I believe you indicated to him that this was an issue with STDOUT
> > output buffering which was internal to Nuke.
>
> It sounds likely.
>
> Try running the command line of nuke from a shell prompt,
> and redirect the output to a file, eg:
>
> nuke -arg1 -arg2 .. > file.out 2>&1
>
> ..and while that is running, open another window, and try to look
> at the contents of the file.out file, eg:
>
> UNIX: tail -f file.out
> WINDOWS: type file.out
>
> If you don't see any output until the render is done or close to done,
> yes, that is the problem.
>
> If you /do/ see the output (eg. if file.out is on a local drive),
> then it might be a problem with the file server.
>
> If you think it's the file server, then try the same thing,
> but:
>
> 1) do the test on a render node
> 2) redirect the output to a file /on the file server/, eg:
>
> nuke -arg1 -arg2 .. > //yourserver/somedir/file.out 2>&1
>
> and then, instead of opening another shell on the same render node,
> open a shell on a workstation (or some *other* render node)
> and try to inspect the file, eg:
>
> UNIX: tail -f /yourserver/somedir/file.out
> WINDOWS: type \\yourserver\somedir\file.out
>
> If you only see the 'delayed output' problem that way, then it's
> possible this can be corrected, as likely the issue you have is:
>
> 1) Your render nodes windows
> 2) Your file server is unix running samba
> 3) You have "oplocks" enabled in your samba config
>
> If that's the case, turning oplocks off in your smb.conf file
> for the volume may solve it. This disables client side caching
> that can cause write buffering to happen at the render node
> when it shouldn't, because samba has some long standing compatibility
> bug with window's client side file caching.
>
> If so, this issue is covered somewhat here:
>
> http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+801+802+803+805+807+808+810
>
> I've seen this problem many times over the last 10 years,
> and in this particular case, has nothing to do with the
> renderer in question.
>
> However, if that's not it, then yes, it might very well be
> stdout buffering in nuke, and you /might/ be able to fix it
> yourself if you can use the correct python or tcl calls to
> disable stdout buffering on nuke start-up. In python, there
> are apparently several ways to disable output buffering:
> http://stackoverflow.com/questions/107705/python-output-buffering
>
> ..which mentions:
>
> 1. Use the python "-u" command line switch
> 2. Wrap sys.stdout in an object that flushes after every write
> 3. Set PYTHONUNBUFFERED env var
> 4. sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
>
> I'd say in your case option 4 might work.
>
> You might also ask the Nuke folks about this; assuming you
> can replicate the first case above (eg. redirecting to a /local/
> file and getting delayed buffered output), then ask the nuke dudes
> about disabling output buffering, citing that test case.
>
> But /don't/ bother the Nuke folks if you have the samba issue
> above (second case), as that's nothing to do with nuke, and
> everything to do with the file server's own config.
>
>
> --
> Greg Ercolano, erco@(email surpressed)
> Seriss Corporation
> Rush Render Queue, http://seriss.com/rush/
> Tel: +1 626-576-0010 ext.23
> Fax: +1 626-576-0020
> Cel: +1 310-266-8906
>
|