:27
To: slurm-users@lists.schedmd.com
Subject: Re: [slurm-users] srun: job steps and generic resources
If those sruns are wrapped in salloc, they work correctly. The first srun can
be eliminated by adding SallocDefaultCommand for salloc (disabled in this
example with --no-shell)
SallocDefaultCommand
___
From: Chrysovalantis Paschoulas
Sent: Friday, December 13, 2019 13:05
To: Kraus, Sebastian
Subject: Re: [slurm-users] srun: job steps and generic resources
Hi Sebastian,
the first srun uses the gres you requested and the second waits for it
to be available again.
You have t
. Juni 135
10623 Berlin
Tel.: +49 30 314 22263
Fax: +49 30 314 29309
Email: sebastian.kr...@tu-berlin.de
From: Chrysovalantis Paschoulas
Sent: Friday, December 13, 2019 13:05
To: Kraus, Sebastian
Subject: Re: [slurm-users] srun: job steps and generic res
The gres resource is allocated by the first srun, the second srun is waiting for
the gres allocation to be free.
If you were to replace that second srun with 'srun -l --gres=gpu:0 hostname' it
will complete, but it will not have access to the GPUs.
You can use salloc instead of the srun to cr
Dear all,
I am facing the following nasty problem.
I use to start interactive batch jobs via:
srun -ppartition -N1 -n4 --time=00:30:00 --mem=1G -Jjobname --pty /bin/bash -il
Then, explicitly starting a job step within such a session via:
srun -l hostname
works fine.
But, as soon as I add a generic
