Dylan Penhale wrote:
Another thing. When I kill the rshd..
rshd or rushd?
I'm guessing you mean rushd, as rush doesn't make use of rsh or rshd.
Not sure why you're killing rushd. You should probably just requeue
the frame via irush (or via 'rush -que') so the script and its
process hierarchy get killed correctly.
If you try to kill the mayabatch process, the render script will probably
think the render failed due to an error, and it's retrying up to three
times before giving up on the machine. (The user probably has "Retries: 3"
set when they submitted the job; this retry behavior is in the render script)
I notice mayabatch restart several times afterwards.
mayabatch, or shake? (This thread is about a problem with shake,
so I guess I'm not sure how mayabatch snuck in.. maybe you're
trying to kill other renders to see if they're affecting shake)
I have to kill it about 3 times. It looks like something
is trying to relaunch it. Would the perl that rush calls do something like
this?
The log for the frame you're trying to kill will probably
show the retry messages from the script.
The way rush kills a frame is to kill the entire process group,
starting at the perl script. So if the process tree is something
like this:
111 rushd
\
112 perl /path/to/renderscript
\
113 maya -batch
..then rush would invoke killpg(2) on PID 112 to kill perl and maya
with a SIGKILL.
Under most versions of Unix I've seen, kill(1) (ie. /bin/kill) can signal
a process group by specifying a negative number for the PID.
Oddly, the OSX man page for kill(1) makes no mention of process groups
at all (!) Maybe this is another great man page omission.
Probably the TCSH and BASH built-in versions of kill(1) support this,
I'm not sure.
The easy thing to do would be to use 'rush -getoff; rush -online'
to quickly kill any renders on the local box, regardless of platform.
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|