From: Greg Ercolano <erco@(email surpressed)> Subject: Re: user environment Date: Fri, 09 Mar 2007 16:37:49 -0500 |
Msg# 1502 View Complete Thread (1 article) | All Threads Last Next |
Dado Feigenblatt wrote: Hi, I've just started on rushI'm trying to send my first simple sphere Maya render to rush but the user environment the job runs in is crippled.I couldn't find anything related to that in the docs. There's a few newsgroup articles that cover this, and the reasons snapshots of user environments are not passed through Rush by default: http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+761+761 ..mainly it's an issue of cross platform and cross-processor (eg. 32 bit library and PATH variables vs 64 bit) compatibility. Also, a rather long history in production administration has taught me that unless there's VERY careful manipulation of user environments (small percentage of the time) this won't work. And even when there *is* a tight reign, if users can change their ~/.cshrc files, they will, and ultimately break them, affecting rendering if these files are used. [EDIT: Also, rush does not tie itself to any shells; Rush doesn't want to know about shells or login specifics; it just wants to run commands, and assumes those commands handle their own environment settings, to ensure the command will run the same no matter which user runs it.] This is why rush does not source or take into account user environments. It's almost always not a good idea, and is a source of random render behavior that's hard to debug. Usually what is needed are variables associated with a particular production, which is often based on the show/shot/element, which one can add logic to the scripts to parse from the scene filenames. See: http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1459+1460+1461+1462 If you're in that small percentage where you have tight reign on user environments and you've somehow got everything working consistently, then you can use the LoadEnvFromCsh() perl function below to source .cshrc files into the perl environment at render time. We use tcsh on Fedora Core 4. Right, and because perl is not a csh based language, it doesn't source csh oriented rc files. To do this, you can use this technique: # LOAD A CSH SCRIPT'S ENVIRONMENT SETTINGS INTO PERL ENVIRONMENT # $1 = csh script to be 'sourced' # Returns: $ENV{} modified as per csh script's settings. # sub LoadEnvFromCsh($) { my ($rcfile) = $_[0]; my $vars = `csh -fc 'source $rcfile; printenv'`; foreach ( split(/\n/, $vars) ) { if ( /(^[^=]*)=(.*)/ ) { $ENV{$1} = $2; } } } ..and just call that in the submit script just before the renderer is invoked (typically in the MAIN_Render() function) Here's a similar function for Bourne Shell (sh, bash) settings e.g. from /etc/profile or /etc/bashrc files: # LOAD A BASH SCRIPT'S ENVIRONMENT SETTINGS INTO PERL ENVIRONMENT # $1 = bash profile to be 'sourced' # Returns: $ENV{} modified as per bash profile's settings. # sub LoadEnvFromBash($) { my ($rcfile) = $_[0]; my $vars = `bash -c '. $rcfile; printenv'`; foreach ( split(/\n/, $vars) ) { if ( /(^[^=]*)=(.*)/ ) { $ENV{$1} = $2; } } } More info on the above here: http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1459+1460+1461+1462 http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+811+811 But beware; sourcing /user/ environments (~/.cshrc) tends to vary widely.. users often have typos in aliases, or invoke programs that makes assumptions about stdout/err being a tty, or play around with the window manager, and that can cause havoc with rendering leading to hard-to-trace problems. If you're sourcing centrally managed files, that's fine (eg. 'source /usr/YOURCOMPANY/adm/.everyone_rc; source /usr/YOURCOMPANY/adm/.maya_8.5') We have a series of config scripts (some in python) that should be sourced for proper user environment setup. Beware of common pitfalls when eg. user handoffs are done. For instance, one user might have maya 8.5 environment variables set up in their ~/.cshrc, and their render works fine when submitted as themselves, but then handing off to a render watcher who resubmits their job doesn't have those settings, the render might fail for them. This kind of problem is avoided if user environments are not allowed into the mix. See the first link above for software specific environment settings, as opposed to sourcing 'user' environments. If you have project-specific settings you're concerned about, often the best way is to add some logic to the submit script that determines the show/shot from the scene file's pathname, eg: http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+761+761 -- Greg Ercolano, erco@(email surpressed) Rush Render Queue, http://seriss.com/rush/ Tel: (Tel# suppressed) Fax: (Tel# suppressed) Cel: (Tel# suppressed) |