From: Craig Allison <craig@(email surpressed)>
Subject: Rendered frame stuck on status "Run"
   Date: Mon, 17 Mar 2008 06:49:45 -0400

Craig Allison wrote:
> Hello!
> 
> I've just upgraded a box to Debian 4 and have installed Shake 4.1,  
> Rush 102.42a.
> 
> The box goes online and picks up jobs fine, it will render the first  
> allocated frame no problem and then when it picks up the next, it  
> renders the frame and gets Shake exit code 0
> but Rush doesn't release the frame and move on.  The box will sit all  
> night with status "Run" even though the log shows an exit code of 0.   
> When you login to the box it will show 2 Shake processes (1 for each  
> cpu) taking 0% CPU.
> 
> Any ideas?

Hi Craig,

	Hit "All Jobs" to make sure you don't have two jobs running
	the same scene and frame range.

	It's possible the log you're looking at that shows the frame
	as 'exit 0' is not the same log as the one that is running the
	frame. A possible situation is if there are *two* jobs both
	running the same shake job and frame range; the stuck job's
	log getting overwritten by the other job that successfully
	ran on a different machine.

	If this were the case, the "Jobid" and "Hostname" field of the
	'Frames' report wouldn't match the same fields in the header
	of the frame log.

	Can you include the "Frames" report from irush showing the
	frame in the Run state, and the *complete* frame log (including
	the headers at the top, and the shake exit message at the bottom)?


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Craig Allison wrote:
> Sorry about the delay getting back on this one, I've been very busy!
> 
> The problem was intermittent but a change of kernel seems to have  
> eradicated the problem altogether...

	Thanks for the follow up, Craig..

	So the problem was with the default Debian 4 + Shake 4.1 combo.
	Interesting.

	Just curious: is it a known issue where a kernel upgrade was
	a known solution, or was it just a happy coincidence?

	If it was a known issue, guess I'd be curious to see any links
	that might have helped you, in case they cover details as to the
	cause, in case it's something I should watch out for across the
	board with linux.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Craig Allison wrote:
> Done 0010     3   render43    4882     render48.62     03/25,17:23:19  00:30:35
> Done 0011     3   render43    4884     render48.62     03/25,17:23:19  00:30:35
> Done 0012     3   render43    4907     render48.62     03/25,17:53:54  00:00:17
> Done 0013     3   render43    4909     render48.62     03/25,17:53:54  00:00:15
> 
> At least the status is not sticking on "Run" but I don't understand  
> why the frames are differing so much - I will let it run on a few  
> more scenes before I hit the panic button!
> 
> Just though I'd leave an update!

	It does seem odd that 4 renders kick in on the box, and two
	take 30 mins to complete, and the other two take 20 seconds.

	I guess jump over to the machine while the frames are taking
	a while, and use 'strace' to see what shake is doing while
	the frames are 'stuck' running, eg:

rsh render43
ps fax				<< determine the PID of the stuck shake process
strace -p <shake_PID>		<< see what shake is doing..

	Also look in the logs while the frames are stuck to see
	if there's any way to tell what shake is doing that it's
	getting stuck on. (Turn on verbose mode if not already..)

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)