From: murphy <murphy@mirage.cz>
Subject: environment variables in win xp 64bit
   Date: Thu, 13 Nov 2008 08:14:34 -0500

Hello,

Now I really do not know what else could be wrong . . . .


thanks

murphy

murphy wrote:
> Hello,
> 
> we have some strange problems rendering maya scene with realflow mesh 
> inside.
> 
> we have a network installation of different maya versions and different 
> platforms. As a central point for preferences, plugins and modules we 
> use MAYA_APP_DIR environment variable pointing to a network disk.
> 
> during rush render maya cries it can not find Reaflowmesh.mll plugin. 
> But when I run rushrender$$$.bat used by rush to render my frames and 
> execute it manually from cmd line it works perfectly and all plugins are 
> successfully loaded.

	Are you running that in a DOS window that's logged in as the
	same user the Rushd service is running as?

	Sometimes permissions on eg. dll files or the directories they're
	in are restrictive enough that only certain users can access them.


> I suspect there is a huge difference running the 
> bat file manually and running the same file from rushd. It seems to me 
> system environments are not visible to mayarender when invoked from rush.
> We have modified our submit to include set MAYA_APP_DIR just before 
> render is executed in our bat file but it did not helped.

	Actually, rush under windows does inherit the combined
	System Environment and User Environment (for the user the
	rushd service is running as), so assuming you've rebooted
	the rendering box since installing the plugin, rush should
	pick up all those environment variables.

	Check to see if the script is changing them around in
	ways where it might loose the values. eg:

$ENV{MAYA_PLUG_IN_PATH} = "/some/path";

	..would overwrite the value of that variable if it were
	correctly in the system environment, whereas:

$ENV{MAYA_PLUG_IN_PATH} = "/some/path;$ENV{MAYA_PLUG_IN_PATH}";

	..would *augment* the path, without stomping on it.

> Now I really do not know what else could be wrong . . . .

	If you think it's an environment issue, try running the
	following from your working DOS window:

set > dos-env.txt

	..and then load that file up, and compare it to the environment
	variable dump in the rush log which you can enable by either changing
	the 'Print Environment:' pulldown from 'No' to 'yes' (In the submit
	form, click on the 'Rush' tab, and scroll down to the bottom to find
	that setting)

	Or, if you've written your own script for submitting, just stick in
	a command just before the render that prints out the environment,
	eg. in the script just before it invokes the renderer, add:

		if ( $G::iswindows ) { print "--- ENVIRONMENT IS:\n"; system("set"); }

	..and that will dump out the environment in the log, so you can compare
	it to the dos-env.txt (above).

Greg Ercolano napsal(a):

	..and that will dump out the environment in the log, so you can compare
	it to the dos-env.txt (above).

I'm confused what could be wrong than . . . :(

thank you very much for your help

murphy


this is output from rushd:

==========================================================================================================
rushd log
==========================================================================================================
ALLUSERSPROFILE=C:\Documents and Settings\All Users
CLASSPATH=.;C:\Program Files (x86)\QuickTime\QTSystem\QTJava.zip
CommonProgramFiles=C:\Program Files (x86)\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=SNAP
ComSpec=C:\WINDOWS\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOME=/temp
LOGNAME=soft
MAYA_APP_DIR=//skserver/oscar/Maya_Custom
MAYA_PLUGIN_PATH=//skserver/oscar/Maya_Custom/2008-x64/plugins
NUMBER_OF_PROCESSORS=2
OS=Windows_NT

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
PROCESSOR_IDENTIFIER=EM64T Family 6 Model 23 Stepping 10, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=170a
ProgramFiles=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
QTJAVA=C:\Program Files (x86)\QuickTime\QTSystem\QTJava.zip
RUSH_DIR=c:\rush
RUSH_FIRST_FRAME=1
RUSH_FRAME=20
RUSH_HOSTNAME=snap
RUSH_ISDAEMON=2024
RUSH_JOBID=snap.554
RUSH_LAST_FRAME=147
RUSH_LOGFILE=//matrix/lima/HighSpeed_SHOWREEL/Bowl/logs/15176_na/0020
RUSH_PADFRAME=0020
RUSH_RAM=1
RUSH_TMPDIR=C:/TEMP/.RUSH_TMP.17
RUSH_TRY=0
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
TERM=unknown
TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
USER=soft
USERDOMAIN=SNAP
USERNAME=Administrator
USERPROFILE=C:\Documents and Settings\Administrator
windir=C:\WINDOWS

Starting "\\skserver\oscar\Maya2008-x64\bin\mayabatch.exe"

Command Line Process Viewer/Killer/Suspender for Windows NT/2000/XP V2.03
Copyright(C) 2002-2003 Craig.Peacock@(email surpressed)
Setting PriorityClass on PID 4272 'mayabatch.exe' to 64
mental ray for Maya 9.0.1
mental ray: version 3.6.51.0, 4 Dec 2007, revision 23078

File read in 0 seconds.

==================================================================================================
dos command line log
==================================================================================================
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\soft\Application Data
CLASSPATH=.;C:\Program Files (x86)\QuickTime\QTSystem\QTJava.zip
CLIENTNAME=Console
com.adobe.versioncue.client.applocale=cs_CZ
com.adobe.versioncue.client.appname=AdobeDrive
com.adobe.versioncue.client.appversion=1.0.0
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
COMPUTERNAME=SNAP
ComSpec=C:\WINDOWS\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\soft
LOGONSERVER=\\SNAP
MAYA_APP_DIR=//skserver/oscar/Maya_Custom
MAYA_PLUGIN_PATH=//skserver/oscar/Maya_Custom/2008-x64/plugins
NUMBER_OF_PROCESSORS=2
OS=Windows_NT

Files (x86)\QuickTime\QTSystem\;C:\Cinetools\Phantom
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=EM64T Family 6 Model 23 Stepping 10, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=170a
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
PROMPT=$P$G
QTJAVA=C:\Program Files (x86)\QuickTime\QTSystem\QTJava.zip
RUSH_DIR=c:\rush
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\DOCUME~1\soft\LOCALS~1\Temp
TMP=C:\DOCUME~1\soft\LOCALS~1\Temp
USERDOMAIN=SNAP
USERNAME=soft
USERPROFILE=C:\Documents and Settings\soft
windir=C:\WINDOWS

Starting "\\skserver\oscar\Maya2008-x64\bin\mayabatch.exe"
mental ray for Maya 9.0.1
mental ray: version 3.6.51.0, 4 Dec 2007, revision 23078
File read in 0 seconds.

mental ray: got 8 satellite CPUs.

Info: (mental ray) : number of render thread(s): 2
MEM  0.0  info : heap size limit set to 3084 MB
JOB  0.0  info : slave rendering OFF
Info: (Mayatomr.Nodes) : custom string options found

Info: (Mayatomr.Scene) : update lights and related shaders
Prog: (Mayatomr.Scene) : DAG node: spotLight1
Prog: (Mayatomr.Scene) : DAG node: spotLight2
Prog: (Mayatomr.Scene) : DAG node: directionalLight1specular
Info: (Mayatomr.Scene) : update cameras and related shaders
Info: (Mayatomr.Scene) : update geometry and materials
Prog: (Mayatomr.Scene) : DAG node: pPlane1
Prog: (Mayatomr.Scene) : DAG node: pPlane5
Prog: (Mayatomr.Scene) : DAG node: RealflowMesh1
Prog: (Mayatomr.Scene) : DAG node: Miska_Poly2
Info: (Mayatomr.Scene) : render camera: camera1
SCEN 0.2  progr: begin scene preprocessing for frame 22
===========================================================================================================================

A few things catch my eye:

	1) There's a subtle difference in the variable names:

	   MAYA_PLUGIN_PATH  -- variable set in both DOS and RUSH
           MAYA_PLUG_IN_PATH  -- variable maya is complaining about

	   Note the difference between these names "PLUGIN" vs. "PLUG_IN";

	   Possibly maya honors both, but in my experience, MAYA_PLUG_IN_PATH
           is the correct variable name.

	2) The plugin path is pointing to a file server:

MAYA_PLUGIN_PATH=//skserver/oscar/Maya_Custom/2008-x64/plugins

	   Since the problem seems user oriented, I can't help but wonder
	   if permissions are causing the trouble.

	   If you login as the same user rushd is running as (local Administrator),
	   can you then open a DOS window and run the render?

	   Does this user have permission to access the plugins directory,
	   eg. does this command work?

dir \\skserver\oscar\Maya_Custom\2008-x64\plugins\

	   If that command fails when logged in as Administrator,
	   but works when logged in as 'soft', the problem is likely
	   the server 'skserver' has a different Administrator password
	   than host 'snap', which means the local Administrator won't
	   have access permission to that server unless the passwords match up.

	3) I notice the rushd service is running as "Administrator"
	   whereas your DOS tests  are being run as "soft".

	   If you login to the window manager as Administrator,
	   are you able to replicate the same error rushd does?

	   Also, if the render runs OK for soft, then try running the
	   rushd service as "soft"; does the render then run normally?

murphy

murphy wrote:
> [posted to rush.general]
> 
> we did last test and rerun the rushd under normal system account. 
> previously it was run under Administrator account and it works now!

	If it's running as the system account, that means rushd will
	run as whomever your window manager is logged in as.

	If that user is "soft", that's probably why it works (see my last message).

	If that's the case, try configuring the rushd service to run as 'soft',
	so that the daemon remains running as that user, regardless of who's
	logged into the machine.

	I do not recommend you run rushd as the 'normal system account',
	because then rushd will not operate unless someone is logged in,
	and it will stop short if someone logs out/in as someone else.

	I'd suggest seeing my last message for a few tests.

	My guess is this is not environment oriented, but rather user
	permission oriented. Probably the local Administrator does not
	have access to the //skserver/oscar volume because the local
	administrator's password doesn't match the one on skserver,
	causing file access not to be available.

Possible Solutions:
	If you want rushd to run as "administrator", then make sure
	the password on "snap" is the same as the local admin's password
	on "skserver", so that the permissions match up.

	*Or*, if matching the administrator's passwords are not possible,
	then consider configuring Rushd to run as the user 'soft' instead,
	since that user probably has matching passwords with skserver,
	and might be why it works from your DOS window tests as 'soft',
	(and when you have rushd set up to run as the 'system' account)

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

Greg Ercolano napsal(a):

murphy wrote:

[posted to rush.general]

	My guess is this is not environment oriented, but rather user
	permission oriented. Probably the local Administrator does not
	have access to the //skserver/oscar volume because the local
	administrator's password doesn't match the one on skserver,
	causing file access not to be available.

Thank you so much for your valuable help Greg!

mur