In the sbatch code, it checks to see if a job name is provided, if so it
will set the SLURM_JOB_NAME environment variable, but since the overwrite
argument of the call is 0, it doesn't do so if the variable is already
set, which is the case you are running into once the first job is
submitted.
if (opt.job_name)
setenv("SLURM_JOB_NAME", opt.job_name, 0);
each successive job is using the already set environment name as the job
name.
One way to accomplish what you are seeking would be to unset the
SLURM_JOB_NAME environment variable prior to making the sbatch call in the
script.
On 10/9/12 9:10 AM, "Carl Schmidtmann" <[email protected]>
wrote:
>
>We've run into a foible of how sbatch sets up the environment for
>scripts...
>
>SLURM_JOB_NAME is supposed to reflect the currently assigned name (-J or
>SBATCH_JOB_NAME), but if you queue up a script from within an executing
>queue script, slurm does not overwrite SLURM_JOB_NAME with a new one
>regardless of what SBATCH_JOB_NAME is set to or the passed -J option.
>
>For example,
>
>#!/bin/bash
>
>echo "My name is $SLURM_JOB_NAME"
>if [ -e halt ] ; then rm halt ; exit 0 ; fi
>sbatch --partition=debug --time=0:1:0 --dependency=afterany:$SLURM_JOB_ID
>--nodes=1 --job-name=bar /path/to/this/script
>touch halt
>sleep 10
>
>
>If I queue this up with,
> sbatch -p debug -t 0:1:0 --nodes 1 --job-name=foo script
>
>The first output will say "My name is foo", but the second one will also
>say "My name is foo".
>
>It turns out that you can change SLURM_JOB_NAME and it will be propagated
>to the next queued script. So inserting,
> SLURM_JOB_NAME=bar
>before the sbatch command works as expected.
>
>
>The other oddity is that the name that shows up in squeue will change.
>Just not the env var...
>
>--
>Carl Schmidtmann
>Center for Integrated Research Computing
>University of Rochester
