Re: [HTCondor-users] parallel job fails to execute

[Jason Patton <jpatton@xxxxxxxxxxx>]

condor_submit does not inspect the submit file to see if getenv is or
is not defined, but it does check that the executable exists, and it
does not use PATH to find the executable. Only the specific path you
give (relative, unless an absolute path is given) is checked for the
executable. So if you put "executable = g09", condor_submit looks for
g09 in the current directory. If it's not there, then you get the
error you mentioned in the first email.

There are many fundamental differences between HTCondor and other
batch scheduling systems, as condor was built with distributed
computing in mind. One of these differences is that condor does not
assume anything about the environment of the execute machine. (Why?
For example, in some condor pools, there may not be a shared file
system. Users may not have a home directory on the execute machines.)
When condor starts a job on an execute machine, the job starter
process creates the environment for the job based only on the
description of the submit file. The job starter process then runs the
executable, which is either (1) condor_exec.exe if the executable was
transferred or is (2) the exact file path given in the submit file if
the executable was not transferred. The job environment's PATH is not
considered by the job starter when running the executable.

The executable itself can make use of environment variables.

If you want to make sure your ~/.bashrc is sourced, you can use a
wrapper script (which can also use environment variables!):

--- wrapper.sh ---
#/usr/bin/env bash
source ~/.bashrc
g06 $@ # run g06 with all the arguments passed to the wrapper script

Then use wrapper.sh for the executable in your submit file. However,
if your .bashrc is the same on the execute nodes as they are on your
submit node, using getenv = true should be good enough.

Jason

On Tue, Feb 20, 2018 at 1:16 AM, Mahmood Naderan <nt_mahmood@xxxxxxxxx> wrote:
> Thanks for the reply. But the getenv is true and that executable is in the
> $PATH. More than that, the program uses some variables that are defined in
> the bashrc. So, I think the full path is not the complete solution for this
> problem.
>
> Regards,
> Mahmood
>
>
>
> On Monday, February 19, 2018, 10:31:17 AM EST, Jason Patton
> <jpatton@xxxxxxxxxxx> wrote:
>
>
> Unless you specify a full path to an executable, condor will try to
> transfer and/or run the executable from the current working directory.
>
> So you can set the full path:
>
> executable = /usr/local/chem/g09-64-D01/g09
> transfer_executable = false
>
> Or use /bin/sh -c if that makes more sense:
>
> command_to_run = g09 test.gjf
> executable = /bin/sh
> transfer_executable = false
> arguments = "-c '$(command_to_run)'"
>
> Jason
>