Hi Em,
this was somehow mentioned in the 20.11.0 Release Notes:
https://github.com/SchedMD/slurm/blob/slurm-20-11-0-1/RELEASE_NOTES
-- By default a step started with srun will get --exclusive behavior meaning
no other parallel step will be allowed to run on the same resources at
the same
Hi, Juergen --
This is really useful information -- thanks for the pointer, and for taking
the time to share!
And, Jacob -- can you point us to any primary documentation based on
Juergen's observation that the change took place with v20.11?
With the emphasis on salloc, I find in the examples:
>
Oh hey this is fun, thanks for sharing. I hadn't seen this, but it works as
advertised.
Jason
On Thu, Nov 3, 2022 at 12:31 AM Christopher Samuel
wrote:
> On 11/2/22 4:45 pm, Juergen Salk wrote:
>
> > However, instead of using `srun --pty bash´ for launching interactive
> jobs, it
> > is now rec
On 11/2/22 4:45 pm, Juergen Salk wrote:
However, instead of using `srun --pty bash´ for launching interactive jobs, it
is now recommended to use `salloc´ and have
`LaunchParameters=use_interactive_step´
set in slurm.conf.
+1 on that, this is what we've been using since it landed.
--
Chris Sa
Hi Em,
this is most probably because in Slurm version 20.11 the behaviour of srun was
changed to not allow job steps to overlap by default any more.
An interactive job launched by `srun --pty bash´ always creates a regular
step (step .0), so mpirun or srun will hang when trying to launch
anoth
Greetings --
When we started using Slurm some years ago, obtaining the interactive
resources through "srun ... --pty bash" was the standard that we adopted.
We are now running Slurm v22.05 (happily), though we noticed recently some
limitations when claiming resources to demonstrate or develop in a
