RE: [Condor-users] Possible Limitation Condor vs Perl /IPC::open3>>>PROBLEM was found, solution to be investigated

[filipdef@xxxxxxxxxxxxxxxxx]

Hi Dave,

One way to deal with this is to define paths/.. in
your local condor config file for each machine:

E.g.


HAS_MAYA_60 = TRUE
HAS_MAX_6 = TRUE

STARTD_EXPRS = HAS_MAYA_60, HAS_MAX_6

JAVA_EXTRA_ARGUMENTS = -Xmx1024M -Dpath.maya.60=/usr/aw/maya6.0
-Djava.io.tmpdir=/tmp -Dpath.max.6=/opt/max/6

Then in your stub, set the environment variable for the
sub processes based on these values (this is again in the java
case, but I'm pretty sure you can do similar things in non java
case, as Ian pointed out).

The thing is that each machine declares its 'capabilities'
and where to find stuff on that machine, and then the stub
sets the correct variables based on that (so this info
doesn't need to be passed in with the job).

Cheers,
- Filip




> | > I will see if by replacing the condor-reuse-vm1 user by
> | another local
> | > user, if that solves the problem.
>
> It did not solve the problem, the env vars for the new account
> Contains the same env var as use "condor-reuse-vm1"
>
> | Dave,
> |
> | Unless you really, really need to use a custom account for
> | the execution of jobs it's safer and easier to just ensure
> | that condor is setting up the environment correctly for the
> | vm1 user and for each of your jobs.
>
> Seems like I won't have any choice ;)
>
> | If you are submitting from an identical windows machine as
> | the one you're running on you can tell condor to copy the
> | entire environment from your submitting machine to the remote
> | machine by adding:
> |
> | getenv = True
>
> We are using a heterogenous renderfarm setup here.
> This will no work, since I can determine if the job will be executed
> On window or linux. Obviously the env var will different depending
> On OS type.
>
> |
> | to your submission ticket. Or if you just want to copy a few
> | environment variables you can do so by adding:
> |
> | environment = PATH|PERL5LIB
> |
> | to your submission ticket. This would ensure that PATH and
> | PERL5LIB were set on the remote machine as they were set on
> | the submitting machine.
> |
> | The other option is to predefine an environment for that
> | startd's on a machine using the STARTER_JOB_ENVIRONMENT
> | configuration setting. For example, to ensure every job that
> | runs on a particular machine knows where to find Perl
> | libraries and Perl you could set:
> |
> | STARTER_JOB_ENVIRONMENT =
> |
> PERL5LIB=c:\MyPerl\site\lib|PATH=C:\MyPerl\bin\;C:\Windows\system32;C:\w
> indows\
>
> I will have to consider conditional env vars such that linux env var
> Gets defined when the job runs on linux machine
>
> Would you know how to create such conditional environment definition
> Based on Ostype?
>
> Maybe I could condor_config.local of each machine to define those env
> var...
>
> | The downside to this approach, especially when using it for
> | PATH settings, is that you have to set EVERYTHING for the
> | variable. You can't
> | (AFAIK) use it to just append to the machine defaults for
> | these variables.
>
> Wow! That is good to know...
>
> | Either approach is better than defining a non-auto created
> | account for job execution. Unless of course you need access
> | to network resources (like remote drives).
>
> Eventually I will need this user to have access to remove drives
> And mount points. I do know there is security holes to do so.
>
> | - Ian
> |
>
> Ian, tx again for your help
> I really appreciate!
>
> _______________________________________________
> Condor-users mailing list
> Condor-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>