Yay! Sharing! https://github.com/atombaby/slurm-drmaa
adds cpus-per-task native specification, corrects mincpu native specification behavior and (IMHO) handles cpu calculations better. On Wed, Apr 9, 2014 at 6:11 AM, E V <[email protected]> wrote: > > I spent some time poking around in the slurm 14.03 code yesterday, and > I don't think it's a slurm-drmaa issue. I think the sbatch code > explicitly sets the SLURM_JOB_NAME env variable itself, it's not set > by any of the core code in slurm. In fact their is no name field in > the job structure that's sent to the slurmd for dispatch. I just > worked around it by adding the var to all jobs environments in my > slurm-drmaa ruby wrapper before hand. Could probably do the same in > slurm-drmaa itself, with more work of course ;-) > > FYI, I put my copy of slurm-drmaa 1.0.7 up on github: > https://github.com/eliv/slurm-drmaa > Currently, just a single commit adding job array support to run_bulk. > > On Tue, Apr 8, 2014 at 7:37 PM, Michael Gutteridge > <[email protected]> wrote: >> >> Don't think you're missing anything. I am getting the same behavior >> on my install (Slurm 2.6.2, slurm-drmaa 1.0.7). Job shows the name in >> squeue's output, but doesn't have the environment variable set. Just >> checking my sanity, if I submit with sbatch -J <name> the environment >> variable is set. >> >> Must be another gap in slurm-drmaa. I've been working with it pretty >> heavily lately- I'll see if I can find anything. >> >> Best >> >> M >> >> On Tue, Apr 8, 2014 at 10:10 AM, E V <[email protected]> wrote: >>> >>> Submitting a job via slurm-drmaa which calls slurm_submit_batch_job() >>> I verified that the job_desc_msg_t passed in as the 1st param has it's >>> .name set to a valid string. However, the submitted job doesn't get >>> it's SLURM_JOB_NAME env variable set. Is this a bug, or am I missing >>> something? >> >> >> >> -- >> Hey! Somebody punched the foley guy! >> - Crow, MST3K ep. 508 -- Hey! Somebody punched the foley guy! - Crow, MST3K ep. 508
