The error can occur on any machine, so the problem is universal, and
the fact that it seems to occur randomly makes it really hard to
troubleshoot. I was hoping someone else had seen the problem, but its
not a show stopper.
I'm going to go ahead and try editing the submit-afterfx.pl and see if
I can just tell it to requeue if it happens, as requeuing will fix the
problem.
Would this be the correct way to add this error handling?
# HANDLE EXIT CODES
if ( $exitcode == 0 ) # OK?
{ print STDERR "\n--- AERENDER SUCCEEDS\n"; exit(0); }
elsif ( $exitcode == 9 ) # WEIRD WRITE PERMISSION ERROR
{ print STDERR "--- AERENDER FAILED...REQUEING:
EXITCODE=$exitcode\n"; exit(2); }
elsif ( $exitcode > 0 && $exitcode < 128 ) # NON-ZERO EXIT
{ print STDERR "--- AERENDER FAILED: EXITCODE=$exitcode\n"; exit(1); }
elsif ( $exitcode ) # SEGFAULT/SIGNAL
{ print STDERR "--- AERENDER FAILED: $errmsg\n"; exit(1); }
I think this should work, but I am no good with perl.
As for the weird automounter issues with /private/var/automount/... I
did a test install of Leopard, and it appears they have fixed
automounts so they mount only at the point specified in LDAP, so thats
good news.
On a side note, I tried the old AFP doesnt support multiple users bug
out in Leopard, and its still broken. Login as User A, with write
priveleges to AFP server 1. Then from the unix prompt, login as User B
with write priveleges to server 1. Yet User B has no priveleges. Booo.
Marco
On 2008-01-24 22:49:27 -0800, Greg Ercolano <erco@(email surpressed)> said:
Does the problem always seem to happen on a particular machine?
Possibly one or two machines don't have the file server mounted
properly.
To troubleshoot, try to replicate the problem from the
command line:
I) Look at one of the frames that fails with the error,
and make note of:
1) the machine it failed on
2) the 'RunningAs:' line in the frame log
II) Login to that machine using either ssh or telnet, logging in
as the same user shown the render was running as (ie. the 'RunningAs:'
line from the frame log)
III) From the unix prompt, try to access the directory in question, eg:
ls -la /private/var/automount/blah/blah
echo hello > /private/var/automount/blah/blah.txt
If you're able to replicate the error, then trouble shoot it that way.
Could be the mount to your file server is not mounted on that machine.
* * *
I should point out the path /private/var/automount/blah/blah
looks wrong.. that should probably be more like /Volumes/blah/blah
Me, I don't trust the automounter, and prefer to making static
mounts by hacking mount commands into the boot scripts, such as
is described in steps #3 and #4 of this article:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1295+1295+1297+1298
Usually it just comes down to a simple command like:
mount -t nfs server:/somedir /jobs/somedir
..where /jobs/somedir is an empty directory that you mount your
file server onto via NFS.
Regardless of if it's a mount problem, or user access problem,
you should be able to replicate the problem from the unix prompt,
assuming you ssh or telnet over to the machine in question and
login as the same user the render was trying to run as.
|