.lock files causing rendering problems

[Sandy Sutherland]

Hi All,

We are using Royal Render here to run the Farm - and are running
Softimage 2010 SP1 - there seems to have been a change in how the
rendering works now - I am no longer seeing a 1K placeholder, but
instead there is a .lock file created - now when the render crashes, it
leaves the .lock file behind - which then causes RR not to re-render the
crashed frame!!

Any ideas why this is happening, and how to stop it???

We are on Win Workstations, and Linux Farm - workstations do hop on
overnight!!

many thanks

Cheers

Sandy

[Mikko Ronkainen]

Hello,
Search found old thread and no replies.

My question on this matter however is slightly different, no RR used. My
simple shell scripts does rendering. On this example removing locks by
script. Is there any harm done removing those .locks and why they are left
behind randomly? Any other solutions. The loop gives nice result while
distributing render.

#render script
#/bin/sh
#1
echo "Bash version ${BASH_VERSION}..."
for i in {1..10}
do
xsi -render /path/to/project/Render_Pictures/*.lock
#or rather path to destination outside project
xsi -render /path/to/project/scene.scn -pass "Default_Pass" -skip on
-RealTimeMessageLogging on
xsi -render /path/to/project/scene.scn -pass "Occlusion_Pass" -skip on
-RealTimeMessageLogging on
xsi -render /path/to/project/scene.scn -pass "Diffuse_Pass" -skip on
-RealTimeMessageLogging on
xsi -render /path/to/project/scene.scn -pass "Ambient_Pass" -skip on
-RealTimeMessageLogging on
xsi -render /path/to/project/scene.scn -pass "Highlight" -skip on
-RealTimeMessageLogging on
echo "Render cycle $i end"
done
#end script

Using XSI 7.01.

.Mikko

[Fabrice Altman]

Hi,

AFAIK there is no harm in removing those randomly created .locks.

Cheers,
F.

[Stephen Blair]

They're not random ;-)

The lock files are created and destroyed as Softimage opens and closes files.
They are a by-product of the OS file i/o calls we use.

Typically, leftover lock files would indicate some "problem" with the network or file server (some kind of latency perhaps?)

[Fabrice Altman]

Mmmmmm Latency perhaps, but not coming from our network or fileserver ;)

[Stephen Blair]

True. Come to think of it, I have repro'd this by starting 10+ concurrent xsibatch render jobs.

[Mikko Ronkainen]

Thanks,
This time they were created render crash, external files path problem,
causes of course infinite latency. User errors rise more randomly software
is used. Also instead of bash csh. For render slave crash, removing .lock
has benefit, this way loop say 10 times will give better result.

.Mikko

[Fabrice Altman]

Pointing the finger at MR/Soft possibly then ? ;)

[Sandy Sutherland]

Rather renders crashing - so not closing elegantly!! Leaving these
files as they go!! :-(

S.

[Fabrice Altman]

What do you mean Sandy?
Are you implying that Soft/MR can possibly sometimes crash whilst rendering, sort of randomly ??? ;)

[Sandy Sutherland]

Egggsssaacccery - do you mean we are THE ONLY ONES??? :-P

S.

[Daniel Harjanto]

Not limit on Workstation service, no?

Cheers,

--
Daniel Harjanto
Infinite Frameworks Studios
TD
http://misterdi.cgpot.com

[Mikko Ronkainen]

Made me laugh. The cause for this time narrowed down to corrupted .map
file, not precisely the path or a latency. Sincerely I've removed them,
time I don't know how long. Some sort of automation is needed.

.Mikko