Note that on 7.8.2, this is called transfer_executable. The
documentation [1] suggest using it for precisely this use-case.
- transfer_executable =
 True | False
- This command is applicable to jobs submitted to the grid
and vanilla universes.
If transfer_executable is set to
False, then Condor looks for the executable on the
remote machine, and
does not transfer the executable over.
This is useful for an already pre-staged executable; Condor
behaves more like rsh.
The default value is True.
For the sake of completeness, some more complex use cases might
do well using a wrapper executable that calls the actual
executable on the worker node. For example, this can be rather
useful if you have a heterogeneous worker node pool where the
executable can be in one of several locations on a node.
Generally, whenever you need some dynamic
validation/staging/modification (that goes beyond what is feasible
to implement in your Condor matching), adding an additional
execution wrapper is a good idea. If your pool is reliably
configured, it's just a waste of time.
-Max
[1]http://research.cs.wisc.edu/htcondor/manual/v7.8.2/condor_submit.html
On 11/21/2012 10:46 PM, Felix
Wolfheimer wrote:
Should_transfer_executable = false
This is what I use to execute a program already present on the
execution host.
Am 21.11.2012 00:09 schrieb "Michael
O'Donnell" < odonnellm@xxxxxxxx>:
I need to write a submit file that
references
an executable on the client side (execute node), but I
recently discovered
that the executable argument specified in the submit file
requires the
executable to exist on the submit machine as well.
Basically, I am referencing
a python executable and I need to reference a 64 bit version
located on
the execute nodes, but not installed on the submit machine.
When I changed
this out an error was thrown stating the executable could
not be found
before the job was queued by HTCondor. I tried removing the
executable
argument in the submit file but this throws an error (a file
and/or path
is required--I was thinking I could include the executable
in the Arguments
parameter of the submit file). So I am wondering if there is
some way to
do this and whether this is the intended functionality
(would make sense
for universe submit jobs where programs are linked, but I am
using a vanilla
job)
I am running HTCondor 7.8.2 on Windows
machines only.
Does anyone have any suggestions on
how I can do this (there are proprietary python modules and
I do not want
to necessarily update python to 64bit on the submit machine.
Although this
behavior seems counter intuitive to me, there is probably a
good reason
I just do not see it yet.
This is an example of one of my submit
files referencing a 32bit python engine, which resides on
the submit node
and execute node:
Universe
= vanilla
Executable
= C:\Python26\ArcGIS10.0\python.exe
run_as_owner
= true
Getenv
= true
Should_transfer_files = no
Requirements
= ( ArcGIS_VS == "10.0" ) && ( OpSys ==
"WINDOWS" || OpSys == "WINNT50" || OpSys == "WINNT51"
|| OpSys == "WINNT60" || OpSys == "WINNT61") &&
(Arch == "INTEL" || Arch == "X86_64" )
Output
=
\\igskbacbvmfscon\condor$\Public\Users\ODonnell\PrjRas\CondorFiles\Logs\Simulations_Step5b\ExtSimVal_1.out
#Use double quotes around entire
Condor
argument
# Use repeated double quotes
around each argument passed to python script
# Use single quotes around
directories
in maxent list of arguments
Arguments
=
"'\\igskbacbvmfscon\condor$\Public\Users\ODonnell\PrjRas\Apps\Simulations\SimulationsData_Extractions_CondorExe.py'
'flt_AOI_10_ced_250_100_sa1_dir2_r1'
flt
'\\igskbacbvmfscon\condor$\Public\Users\ODonnell\PrjRas\Data\Outputs\Simulations_Step5\SASIM_ERDAS\Job_1\flt_AOI_10_ced_250_100_sa1_dir2_r1_Flipped.img''\\igskbacbvmfscon\condor$\Public\Users\ODonnell\PrjRas\Data\Outputs\Simulations_Step5\SASIM_ERDAS\Job_1\flt_AOI_10_ced_250_100_sa1_dir2_r1_pLAEA.img'
'\\igskbacbvmfscon\condor$\Public\Users\ODonnell\PrjRas\Data\Outputs\Simulations_Step5\SASIM_ERDAS\Job_1\flt_AOI_10_ced_250_100_sa1_dir2_r1_pUTM.img'
1"
Notification
= Never
Queue
Thank you for your suggestions,
Mike
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx
with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}