Quoting from PBS PRO version 19 user’s guide:
You can run a PBS job by specifying an executable and its arguments
instead of a job script. When you run qsub this way, it runs the
executable directly. It does not start a shell, so no shell
initialization scripts are run, and execution paths and other
environment variables are not set. There is not an easy way to run
your command in a different directory.
I have a script to run a program like that:
qsub \
-l walltime="3:00:00" \
-q ${queue} \
-- myprogram arguments
The catch is, when I run myprogram like that it will run in the current working directory (cwd), and I would like to run instead in a different working directory which is only visible at runtime, so I cannot just move to the directory wanted and run from there.
Would be great if anyone has found a easy/hard way to run in a different directory a PBS executable job.
P.S: I know SLURM can do this easily with the option -D in sbatch like so:
sbatch \
-D ${my_desired_directory} \
--wrap 'myprogram arguments'
But PBS PRO seems to lack this functionality.
One last thing, this post How to start the PBS Job script in the directory that it was submitted from
did not resolve my issue.
The easy one is obviously to use a script rather than a binary. Many people use this, e.g. doing a cd $PBS_O_HOME to run commands in the directory in which a job was submitted.
But other than that, jobs always start with either the user’s home directory as current working directory or the sandbox as the current working directory (if sandboxes are in use).
Note that since PBS uses execve(), you can continue to use the “-- command” syntax to qsub, since a script with the proper interpreter line as a first line and with ‘x’ permissions can be “run” just as much as a binary.
The easy one is obviously to use a script rather than a binary.
Dear @alexis.cousein, thanks for your answer. Unfortunately, using a script is not possible. I’m passing the qsub call along with -- command to a workflow management system called Cromwell. The workflow creates a directory at runtime and I need to pass a -- command in my case that runs a container (Singularity a container similar to docker) and runs a file within the directory created at runtime.
What do you mean execve() ? I’m not too familiar with PBS.
execve() has a man page, you know ;-). that is the call that the PBS job starter script uses to “become” the command.
I don’t think you understand my point about “command”. You can write a BASH wrapper script (let’s call it “wrapped_command”) that does a cd to whatever directory you like and calls the command you want (possibly passing along the parameters to the script, which may even include the directory you want to cd to), chmod 755 the file, and use that in qsub – wrapped_command.
Please be precise in your terminology: “and runs a file” is hard to understand.
“Using a script is not possible” is not something you have established, just asserted, and I have yet to even see how the rest of the paragraph supports it; you’d have to be a lot more specific about exactly what you’re trying to do. The point is that a script can also be a command. Commands are not always binaries.
PBS does not support -D, so you won’t be able to do exactly what you were doing in SLURM, that is correct.
So instead of
sbatch
-D ${my_desired_directory}
–wrap ‘myprogram arguments’
you’d usually write a small script that does
#!/bin/bash
cd $1
shift
myprogram "$@"
And then you could qsub – wrapped_myprogram ${my_desired_directory} arguments
You could even make a wrapper script that is generic and can be used to run any program by making $1 to the script be the directory, $2 the command to run, and the rest the arguments to the command.
1 Like