Mailing List ArchivesPublic Access |
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesPublic Access |
|
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 HTCondor looks for the executable on the remote machine, and does not transfer the executable over. This is useful for an already pre-staged executable; HTCondor behaves more like rsh. The default value is True.
Hi all,
I am a bit at a loss here, but how can I refer to an executable, that
does not exists on the submitter's context.
I.e., I have a Singularity container where the executable is available under
 /opt/spark/sbin/start-slave.sh
that exists just in the container's context. The job is submitted with
the Singularity image as target.
Also with 'should_transfer_files = NO', condor_submit fails with [1],
since the executable does not exists under the path at submission.
Christoph suggested a detour via /bin/bash as executable and the actual
script/application as argument [2] - which is a bit hacky, but works ;)
So, I wonder if there is a better(?) way/what am I missing here?
Cheers,
 Thomas
[1]
ERROR: Executable file /opt/spark/sbin/start-slave.sh does not exist
[2]
> test.submit
should_transfer_files = NO
Executable  Â= /usr/bin/bash
arguments   = "/opt/spark/sbin/start-slave.sh --port 3100 ..."
...
Queue 1
_______________________________________________
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/