Thanks,
The times were correct via chrony but the timezones were UTC and NZDT which was
the issue. Oddly nodes 1 and 2 didnt care about that, only no3 ***shrug***
regards
Steven
From: Chris Samuel via slurm-users
Sent: Tuesday, 10 December 2024 4:19 pm
To:
you don't need to be a subscriber to search bugs.schedmd.com
On Tue, Dec 10, 2024 at 9:44 AM Davide DelVento via slurm-users
wrote:
>
> Good sleuthing.
>
> It would be nice if Slurm would say something like
> Reason=Priority_Lower_Than_Job_ so people will immediately find the
> culprit in s
Good sleuthing.
It would be nice if Slurm would say something like
Reason=Priority_Lower_Than_Job_ so people will immediately find the
culprit in such situations. Has anybody with a SchedMD subscription ever
asked something like that, or is there some reasons for which it'd be
impossible (or t
Hi Andreas,
many thanks for your reply and for the link to the definition page of
slurm documentation!
Regarding my example, I still have a question: why do you assume that
tasks=cpus?
From the definition of cpu in the documentation I understand that cpus
might refers to threads since I defi
Found the problem: another job was blocking access to the reservation.
The strangest thing is that the node (gpu03) has always been reserved
for a project, the blocking job did not explicitly request it (and even
if it did, it would have been denied access) but its state was:
JobState=PENDING
