Daniel Browne wrote:
> - Our NFS based /Network/Library/Fonts folder is not recognized by AE (I
> believe this has always been the case), so the fonts needed for the scene had
> to be copied locally. So far I've had no success trying to make it recognize
> the central library from environment parameters. This happens even with
> a render user logged in on the console, so it's not an automount issue.
I'd suggest contacting Adobe about that one.
Assuming you can replicate the problem from the command line
(ie. ssh into the remote machine as the same user rush is rendering
the job as when the problem occurs), and then report the problem to
them in that context. Leave "rush" or "we're using a render queue"
out of the support call, so that it doesn't confuse them.
> - In that same vein I cannot centralize plug-ins either. Nor for that matter
> could I centralize the entire AE package itself (even if I didn't have the
> mounts set with the nosuid flag)
Can't answer to this, as I'm not sure what limitations are built
into AE that prevent this.
I have a feeling that AE might still be internally using OS9 techniques
for accessing files (eg. the old "some:path:dir" instead of "/some/path/dir"
pathnames) One can sometimes see those old OS9 style pathnames in AE's output.
I understand they're trying to get away from that old stuff, but it's
been taking them a while because internally Adobe shares the same libraries
among all their products.
Long ago AE had problems accessing files on more than one network volume..
not sure if that's still the case, but I believe that was an OS9 limitation
as well. Might be related.
> - The aerender binary does not seem to return its error number consistently
> on exit; I've had batches register as Done even when they've failed in the
> frame logs, despite what is in my submit script.
Can you include a copy of the complete log from one of these frames?
Then I can help show you what commands to add to the submit script
logic so you can catch those errors and handle them properly.
> Do you know of another way
> or do I simply have to capture the stdout and search for an error message?
stdout/err capture is the only other way, and there's a function
built into the scripts called LogCheck() which lets you specify
one or more regex strings that searches the logs, correctly skipping
over retry attempts.
> - When I fail or dump a batch to re-que it, it doesn't kill the aerendercore
> process and I have to kill it on the individual machine. This is probably
> the most serious problem as often even killing aerendercore isn't enough.
Yes, this is really annoying, details on that were posted
here on the group a few months ago here:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1906+1906
This cropped up because Adobe made a change in CS3 that causes the
render process to disconnect itself from the process hierarchy,
effectively orphaning the process.
Adobe is aware of the problem as of November 2009, and is trying
to fix it. I worked directly with the AE devs on that issue.
The AE engineers came up with a javascript mod as a temporary
workaround to solve the problem; I can try to follow up with
those engineers through myself on your behalf; contact me off list.
This can be replicated from the command line as well by just
running aerender interactively, and then killing it.
You don't have to reboot to fix the problem, you can do something
like a 'killall' command as root to kill the aerendercore and
associated processes.
Until Adobe fixes this, all render queue systems and distributed scripting
of AE is affected by this.
> The kill results in a zombie process that makes it impossible to run another
> render on the machine until you do a "reboot -q" on it.
If you look carefully at the process hierarchy, you can determine which
processes need to be killed.. there's more than one.
Mac's ps(1) command unfortunately doesn't seem to have an equivalent of
the linux 'ps -fax' command, which shows the process hierarchy as a 'tree'
so you can see what's parented to what.
I do, however, have a script on my homepage that does the equivalent
on the mac (and in fact, on most all unix platforms):
http://seriss.com/people/erco/unixtools/piss
..which if you run it, will show you the process tree on a Mac
so you can see which processes are parented to what, and will help you
determine what needs to be killed to free up the box. Example report:
http://seriss.com/people/erco/unixtools/sample-piss.html
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|