- slurm-users - lists.schedmd.com

lua, glib, gtk, kafka not found for slurm 24.11 and Alma 8
by Bernd Melchers 17 Dec '24

17 Dec '24

Dear all, i tried to rpmbuild slurm-24.11.0 for Alma Linux 8. Build failed because some installed Packages are not found by slurms configure script: rdkafka, glib, gtp and lua But all these packages are installed and they are found by slurm-24.05.x: librdkafka-1.6.1-1.el8.x86_64 librdkafka-devel-1.6.1-1.el8.x86_64 lua-5.3.4-12.el8.x86_64 lua-devel-5.3.4-12.el8.x86_64 glib2-2.56.4-165.el8_10.x86_64 glib2-devel-2.56.4-165.el8_10.x86_64 gtk2-2.24.32-5.el8.x86_64 gtk2-devel-2.24.32-5.el8.x86_64 gtk3-3.22.30-12.el8_10.x86_64 gtk3-devel-3.22.30-12.el8_10.x86_64 Mit freundlichen Grüßen Bernd Melchers -- Archiv- und Backup-Service | fab-service(a)zedat.fu-berlin.de Freie Universität Berlin | Tel. +49-30-838-55905

2 3

AllocNode:Sid in scontrol but not sacct?
by Chris Taylor 16 Dec '24

16 Dec '24

Does the accounting database keep this? Maybe I'm missing something but I don't see a way to query for it in sacct. Chris

1 1

job_container/tmpfs, TmpFS and TmpDisk usage
by Paul Musset 16 Dec '24

16 Dec '24

Hello, I have multiple questions about the usage of job_container/tmpfs, and the TmpFS and TmpDisk variables 1) If my job_container.conf files contains: ``` BasePath=/mnt/slurm_tmp Shared=true ``` is it important what I set TmpFS to in slurm.conf ? Should I set it to '/mnt/slurm_tmp' or '/tmp' ? 2) What size should I put in TmpDisk ? the size advertised by df ? 3) Finally, is there any recommended file system for the partition used as the job_container/tmpfs BasePath ? Best regards, Paul Musset Max Planck Institute for Brain Research

1 0

Difference between sreport's cpu time usage and sacct -j usage
by KK 14 Dec '24

14 Dec '24

Hi all, I have observed a significant discrepancy in CPU usage time calculations between sreport and sacct, and I would like to understand the underlying cause. Let me share the specific case I encountered when calculating CPU usage time for user zt23132881r from November 1, 2024, to November 30, 2024. 1. sreport Results (995,171 minutes): -------------------------------------------------------------------------------- *[root@master ~]# sreport Cluster UserUtilizationByAccount user=zt23132881r start=2024-11-01 end=2024-11-30--------------------------------------------------------------------------------Cluster/User/Account Utilization 2024-11-01T00:00:00 - 2024-11-29T23:59:59 (2505600 secs)Usage reported in CPU Minutes-------------------------------------------------------------------------------- Cluster Login Proper Name Account Used Energy--------- --------- --------------- --------------- -------- ---------djhpc-po+ zt231328+ zt23132881r zt+ zt23132881r_ba+ 995171 6294875* 2. sacct Results: # Without truncate (1,019,927 minutes / 61,195,668 seconds) *[root@master ~]# sacct -u zt23132881r -S 2024-11-01 -E 2024-11-30 -o "jobid,partition,account,user,alloccpus,cputimeraw,state" -X |awk 'BEGIN{total=0}{total+=$6}END{print total}'61195668* # With truncate (967,165 minutes / 58,029,908 seconds) *[root@master ~]# sacct -u zt23132881r -S 2024-11-01 -E 2024-11-30 -o "jobid,partition,account,user,alloccpus,cputimeraw,state" -X --truncate |awk 'BEGIN{total=0}{total+=$6}END{print total}'58029908* # No -X *[root@master ~]# sacct -u zt23132881r -S 2024-11-01 -E 2024-11-30 -o "jobid,partition,account,user,alloccpus,cputimeraw,state" |awk 'BEGIN{total=0}{total+=$6}END{print total}'61195668* The results show three different values: - *sreport: 995,171 minutes* - *sacct (without truncate): 1,019,927 minutes* - *sacct (with truncate): 967,165 minutes* I would appreciate if someone could explain: - Which of these results is more accurate? - How does sreport calculate CPU usage time? - Why does the --truncate option in sacct lead to different results? Thank you for your assistance in clarifying these discrepancies. Best regards

2 1

Node configuration unavailable when using --mem-per-gpu , for specific GPU type
by Matthew R. Baney 13 Dec '24

13 Dec '24

Hi all, I'm seeing some odd behavior when using the --mem-per-gpu flag instead of the --mem flag to request memory when also requesting all available CPUs on a node (in this example, all available nodes have 32 CPUs): $ srun --ntasks-per-node=8 --cpus-per-task=4 --gpus-per-node=gtx1080ti:1 --mem-per-gpu=1g --pty bash srun: error: Unable to allocate resources: Requested node configuration is not available $ srun --ntasks-per-node=8 --cpus-per-task=4 --gpus-per-node=gtx1080ti:1 --mem=1g --pty bash srun: job 3479971 queued and waiting for resources srun: job 3479971 has been allocated resources $ The nodes in this partition have a mix of gtx1080ti and rtx2080ti GPUs, but only one type of GPU is in any one node. The same behavior does not occur when requesting a (node with a) rtx2080ti instead. Is there something I'm missing that would cause the --mem-per-gpu flag to not be working in this example? Thanks, Matthew

1 0

Adding gres usage to the accounting database
by Mark Dixon 13 Dec '24

13 Dec '24

Hello! Our jobs can ask for dedicated per-node disk space, e.g. "--gres=tmp:1G", where an ephemeral directory is managed by the site prolog/epilog and usage is capped using an xfs project quota. This works well, although we really need to look at job_container/tmpfs. I note that slurm already periodically polls jobs for their memory usage, which finds its way into the accounting database tres_usage fields. What would be really nice is if we could extend this polling so that we feed our xfs project quota utilisation into the accounting database, too: users get feedback on what their jobs need, and we notice people who ask for a fraction of a node and all of the disk space, but not use it. Slurm is famous for being extendible. Is there some sort of plugin hook someone can point me at to have a go with, or am I missing a simpler method, please? Thanks! Mark

1 0

Slurm version 24.05.5 is now available
by Marshall Garey 12 Dec '24

12 Dec '24

We are pleased to announce the availability of Slurm version 24.05.5. This release fixes a few potential crashes, several stepmgr bugs, compatibility for sstat and sattach with newer version steps, and some other minor bugs. Downloads are available at https://www.schedmd.com/downloads.php . -- Marshall Garey Release Management, Support, and Development SchedMD LLC - Commercial Slurm Development and Support > * Changes in Slurm 24.05.5 > ========================== > -- Fix issue signaling cron jobs resulting in unintended requeues. > -- Fix slurmctld memory leak in implementation of HealthCheckNodeState=CYCLE. > -- job_container/tmpfs - Fix SLURM_CONF env variable not being properly set. > -- sched/backfill - Fix job's time_limit being overwritten by time_min for job > arrays in some situations. > -- RoutePart - fix segfault from incorrect memory allocation when node doesn't > exist in any partition. > -- slurmctld - Fix crash when a job is evaluated for a reservation after > removal of a dynamic node. > -- gpu/nvml - Attempt loading libnvidia-ml.so.1 as a fallback for failure in > loading libnvidia-ml.so. > -- slurmrestd - Fix populating non-required object fields of objects as '{}' in > JSON/YAML instead of 'null' causing compiled OpenAPI clients to reject > the response to 'GET /slurm/v0.0.40/jobs' due to validation failure of > '.jobs[].job_resources'. > -- Fix sstat/sattach protocol errors for steps on higher version slurmd's > (regressions since 20.11.0rc1 and 16.05.1rc1 respectively). > -- slurmd - Avoid a crash when starting slurmd version 24.05 with > SlurmdSpoolDir files that have been upgraded to a newer major version of > Slurm. Log warnings instead. > -- Fix race condition in stepmgr step completion handling. > -- Fix slurmctld segfault with stepmgr and MpiParams when running a job array. > -- Fix requeued jobs keeping their priority until the decay thread happens. > -- slurmctld - Fix crash and possible split brain issue if the > backup controller handles an scontrol reconfigure while in control > before the primary resumes operation. > -- Fix stepmgr not getting dynamic node addrs from the controller > -- stepmgr - avoid "Unexpected missing socket" errors. > -- Fix `scontrol show steps` with dynamic stepmgr > -- Support IPv6 in configless mode

1 0

node3 not working - down
by Steven Jones 10 Dec '24

10 Dec '24

Hi, As suggested, 8><--- Stop their services, start them manually one by one (ctld first), then watch whether they talk to each other, and if they don't, learn what stops them from doing so - then iterate editing the config, "scontrol reconfig", lather, rinse, repeat. 8><--- Error logs, On node3, ======== [2024-12-09T21:43:10.694] slurmd started on Mon, 09 Dec 2024 21:43:10 +0000 [2024-12-09T21:43:10.694] CPUs=20 Boards=1 Sockets=20 Cores=1 Threads=1 Memory=48269 TmpDisk=23308 Uptime=3703 CPUSpecList=(null) FeaturesAvail=(null) FeaturesActive=(null) [2024-12-09T23:38:56.645] error: Munge decode failed: Rewound credential [2024-12-09T23:38:56.645] auth/munge: _print_cred: ENCODED: Tue Dec 10 23:38:30 2024 [2024-12-09T23:38:56.645] auth/munge: _print_cred: DECODED: Mon Dec 09 23:38:56 2024 [2024-12-09T23:38:56.645] error: Check for out of sync clocks [2024-12-09T23:38:56.645] error: slurm_receive_msg_and_forward: g_slurm_auth_verify: REQUEST_PING has authentication error: Invalid authentication credential [2024-12-09T23:38:56.645] error: slurm_receive_msg_and_forward: Protocol authentication error [2024-12-09T23:38:56.655] error: service_connection: slurm_receive_msg: Protocol authentication error [2024-12-10T01:13:18.454] Slurmd shutdown completing ====== I have checked the time, this is fine munge.key I ran md5sum over it and get the same output. When I reboot the warewulf nodes its a common Container file so 1~2 working but not 3 is just wierd. On the controller, ========= [2024-12-10T01:30:35.108] Node node2 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:35.109] Node node1 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:35.109] Node node6 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:35.109] Node node7 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:35.110] Node node3 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:35.110] Node node5 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:35.110] Node node4 appears to have a different version of Slurm than ours. Please update at your earliest convenience. [2024-12-10T01:30:36.104] SchedulerParameters=default_queue_depth=100,max_rpc_cnt=0,max_sched_time=2,partition_job_depth=0,sched_max_job_start=0,sched_min_interval=2 ========== So the controller is RHEL9 and the nodes Rocky8 However 1~2 and 4~7 work OK. When I run, [root@vuwunicoslurmd1 log]# scontrol show node node3 NodeName=node3 Arch=x86_64 CoresPerSocket=1 CPUAlloc=0 CPUEfctv=20 CPUTot=20 CPULoad=0.00 AvailableFeatures=(null) ActiveFeatures=(null) Gres=(null) NodeAddr=node3 NodeHostName=node3 Version=20.11.9 OS=Linux 4.18.0-553.30.1.el8_10.x86_64 #1 SMP Tue Nov 26 18:56:25 UTC 2024 RealMemory=48000 AllocMem=0 FreeMem=43378 Sockets=20 Boards=1 State=DOWN ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A Partitions=debug BootTime=2024-12-09T20:41:27 SlurmdStartTime=2024-12-10T01:13:25 LastBusyTime=2024-12-10T01:30:31 CfgTRES=cpu=20,mem=48000M,billing=20 AllocTRES= CapWatts=n/a CurrentWatts=0 AveWatts=0 ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s Reason=Node unexpectedly rebooted [slurm@2024-12-09T20:40:27] [root@vuwunicoslurmd1 log]# I get a reason, its like the node is held down / off, does this need to be / can this be cleared? regards Steven

2 2

Job not starting
by Diego Zuccato 10 Dec '24

10 Dec '24

Hello all. An user reported that a job wasn't starting, so I tried to replicate the request and I get: -8<-- [root@ophfe1 root.old]# scontrol show job 113936 JobId=113936 JobName=test.sh UserId=root(0) GroupId=root(0) MCS_label=N/A Priority=1 Nice=0 Account=root QOS=long JobState=PENDING Reason=Priority Dependency=(null) Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0 RunTime=00:00:00 TimeLimit=2-00:00:00 TimeMin=N/A SubmitTime=2024-12-06T13:19:36 EligibleTime=2024-12-06T13:19:36 AccrueTime=2024-12-06T13:19:36 StartTime=Unknown EndTime=Unknown Deadline=N/A SuspendTime=None SecsPreSuspend=0 LastSchedEval=2024-12-06T13:21:32 Scheduler=Backfill:* Partition=m3 AllocNode:Sid=ophfe1:855189 ReqNodeList=(null) ExcNodeList=(null) NodeList= NumNodes=1-1 NumCPUs=96 NumTasks=96 CPUs/Task=1 ReqB:S:C:T=0:0:*:* TRES=cpu=96,mem=95000M,node=1,billing=1296 Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=* MinCPUsNode=1 MinMemoryNode=95000M MinTmpDiskNode=0 Features=(null) DelayBoot=00:00:00 OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null) Command=/home/root.old/test.sh WorkDir=/home/root.old StdErr=/home/root.old/%N-%J.err StdIn=/dev/null StdOut=/home/root.old/%N-%J.out Power= [root@ophfe1 root.old]# scontrol sho partition m3 PartitionName=m3 AllowGroups=ALL DenyAccounts=formazione AllowQos=ALL AllocNodes=ALL Default=NO QoS=N/A DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO MaxNodes=UNLIMITED MaxTime=UNLIMITED MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED Nodes=mtx20 PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO OverTimeLimit=NONE PreemptMode=CANCEL State=UP TotalCPUs=192 TotalNodes=1 SelectTypeParameters=CR_SOCKET_MEMORY JobDefaults=(null) DefMemPerNode=UNLIMITED MaxMemPerNode=UNLIMITED TRES=cpu=192,mem=1150000M,node=1,billing=2592 TRESBillingWeights=CPU=13.500,Mem=2.2378G [root@ophfe1 root.old]# scontrol show node mtx20 NodeName=mtx20 Arch=x86_64 CoresPerSocket=24 CPUAlloc=0 CPUEfctv=192 CPUTot=192 CPULoad=0.00 AvailableFeatures=ib,matrix,intel,avx ActiveFeatures=ib,matrix,intel,avx Gres=(null) NodeAddr=mtx20 NodeHostName=mtx20 Version=22.05.6 OS=Linux 4.18.0-372.9.1.el8.x86_64 #1 SMP Tue May 10 14:48:47 UTC 2022 RealMemory=1150000 AllocMem=0 FreeMem=1156606 Sockets=4 Boards=1 MemSpecLimit=2048 State=IDLE ThreadsPerCore=2 TmpDisk=0 Weight=8 Owner=N/A MCS_label=N/A Partitions=m3 BootTime=2024-12-06T10:01:42 SlurmdStartTime=2024-12-06T10:02:54 LastBusyTime=2024-12-06T10:51:58 CfgTRES=cpu=192,mem=1150000M,billing=2592 AllocTRES= CapWatts=n/a CurrentWatts=0 AveWatts=0 ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s -8<-- So the node is free, the partition does not impose extra limits (used only for accounting factors) but the job does not start. Any hints? Tks -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786

3 5

TRES cpu vs tasks
by Miriam Olmi 10 Dec '24

10 Dec '24

Hi all, I cannot understand the true difference and definition of "core", "task" and "cpu" within the limits associated to a partition via the TRES variable of a QOS. More precisely I have 2 partitions defined as follows: PartitionName=lprod AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL AllocNodes=ALL Default=NO QoS=lprod_part DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO MaxNodes=UNLIMITED MaxTime=1-00:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED MaxCPUsPerSocket=UNLIMITED Nodes=r037c01s[01-12] PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO OverTimeLimit=NONE PreemptMode=OFF State=UP TotalCPUs=432 TotalNodes=12 SelectTypeParameters=NONE JobDefaults=(null) DefMemPerNode=UNLIMITED MaxMemPerNode=UNLIMITED TRES=cpu=432,mem=12M,node=12,billing=432 PartitionName=bprod AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL AllocNodes=ALL Default=NO QoS=bprod_part DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO MaxNodes=UNLIMITED MaxTime=1-00:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED MaxCPUsPerSocket=UNLIMITED Nodes=r037c01s[01-12] PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO OverTimeLimit=NONE PreemptMode=OFF State=UP TotalCPUs=432 TotalNodes=12 SelectTypeParameters=NONE JobDefaults=(null) DefMemPerNode=UNLIMITED MaxMemPerNode=UNLIMITED TRES=cpu=432,mem=12M,node=12,billing=432 with the two qos defined as: Name Priority GraceTime PreemptMode UsageFactor MaxJobsPU MaxSubmitPU MaxTRES MinTRES Flags -------------------- ---------- ---------- ----------- ----------- --------- ----------- -------------------- -------------------- -------------------------------------------------- lprod_part 0 00:00:00 cluster 1.000000 100 120 cpu=32,mem=366G cpu=1 DenyOnLimit,PartitionMaxNodes,PartitionMinNodes bprod_part 0 00:00:00 cluster 1.000000 100 120 cpu=64,mem=366G cpu=33 DenyOnLimit,OverPartQOS If I try to submit a job on the lprod partition with the directives: #SBATCH --nodes=12 #SBATCH --ntasks-per-node=1 the job is executed correctly while it is not executed if submitted on the bprod partition due to the error: sbatch: error: QOSMinCpuNotSatisfied sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits) I understand that this is related to the limit of cpu associated to the partition via the qos: lprod->[1-32]cpus, bprod->[33-64]cpus but I would like to have a more proper explanation since the options I am using are not referring to "cpu" but to "tasks" and I could not find a proper definition of "cpu" in the framework of the TRES. Many thanks in advance. Best, Miriam

2 2

slurm nodes showing down*
by Steven Jones 09 Dec '24

09 Dec '24

I have just rebuilt all my nodes and I see Only 1 & 2 seem available? While 3~6 are not 3's log, [root@node3 log]# tail slurmd.log [2024-12-08T21:45:51.250] CPU frequency setting not configured for this node [2024-12-08T21:45:51.251] slurmd version 20.11.9 started [2024-12-08T21:45:51.252] slurmd started on Sun, 08 Dec 2024 21:45:51 +0000 [2024-12-08T21:45:51.252] CPUs=20 Boards=1 Sockets=20 Cores=1 Threads=1 Memory=48269 TmpDisk=23324 Uptime=30 CPUSpecList=(null) FeaturesAvail=(null) FeaturesActive=(null) [root@node3 log]# And 7 doesnt want to talk to the controller. [root@node7 slurm]# sinfo slurm_load_partitions: Zero Bytes were transmitted or received [root@node7 slurm]# These are all rebuilt and 1~3 are identical and 4~7 are identical. 7's log keep saying, [2024-12-08T21:49:17.246] error: Unable to register: Zero Bytes were transmitted or received [2024-12-08T21:49:18.263] error: Unable to register: Zero Bytes were transmitted or received [2024-12-08T21:49:19.278] error: Unable to register: Zero Bytes were transmitted or received [2024-12-08T21:49:20.294] error: Unable to register: Zero Bytes were transmitted or received [2024-12-08T21:49:21.310] error: Unable to register: Zero Bytes were transmitted or received [root@vuwunicoslurmd1 slurm]# sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 2 idle* node[1-2] debug* up infinite 4 down* node[3-6] [root@vuwunicoslurmd1 slurm]# regards Steven

2 4

error and output files
by michaelmorgan937＠gmail.com 09 Dec '24

09 Dec '24

Hi all, I have a program (for example x.x). When I run it as "x.x -I input -o output", I will get an "output" file, as well as output and error files from slurm. However, all the content of slurm output file is in the "output" file (and there are some extra content), so it is a waste to print the slurm output. Is it possible to set directives so that slurm only print error file? Thank you very much. Michael Morgan

2 1

Why is my job killed when ResumeTimeout is reached instead of it being requeued?
by Xaver Stiensmeier 09 Dec '24

09 Dec '24

Dear Slurm-user list, when a job fails because the node startup fails (cloud scheduling), the job should be re-queued: Resume Timeout Maximum time permitted (in seconds) between when a node resume request is issued and when the node is actually available for use. Nodes which fail to respond in this time frame will be marked DOWN and the jobs scheduled on the node requeued. however, instead of requeuing the job, it is killed. [2024-11-18T10:41:52.003] node bibigrid-worker-wubqboa1z2kkgx0-0 not resumed by ResumeTimeout(1200) - marking down and power_save [2024-11-18T10:41:52.003] Killing JobId=1 on failed node bibigrid-worker-wubqboa1z2kkgx0-0 [2024-11-18T10:41:52.046] update_node: node bibigrid-worker-wubqboa1z2kkgx0-0 reason set to: FailedStartup [2024-11-18T10:41:52.046] power down request repeating for node bibigrid-worker-wubqboa1z2kkgx0-0 Our ResumeProgram does not change the state of the underlying workers, I think we should set the nodes to DOWN explicitly if the startup fails given: *ResumeProgram* is unable to restore a node to service with a responding slurmd and an updated BootTime, it should set the node state to DOWN, which will result in a requeue of any job associated with the node - this will happen automatically if the node doesn't register within ResumeTimeout but in any case as we can see in the log the job should be requeued based on it reaching the ResumeTimeout alone. I am unsure why that is not happening. The power down request is sent by the ResumeFailProgram. We have SlurmctldParameters=idle_on_node_suspend activated, but that shouldn't affect Resume, I guess. My Slurm version is slurm 23.11.5 Best regards, Xaver # More context ## Slurmctld from submitting job to failure [2024-11-18T10:21:45.490] sched: _slurm_rpc_allocate_resources JobId=1 NodeList=bibigrid-worker-wubqboa1z2kkgx0-0 usec=1221 [2024-11-18T10:21:45.499] debug: sackd_mgr_dump_state: saved state of 0 nodes [2024-11-18T10:21:58.387] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:21:58.387] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:22:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:23:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:23:20.009] debug: sackd_mgr_dump_state: saved state of 0 nodes [2024-11-18T10:23:23.003] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:23:23.398] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:23:23.398] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:23:53.398] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:23:53.398] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:24:21.000] debug: sched: Running job scheduler for full queue. [2024-11-18T10:24:21.484] slurmscriptd: error: _run_script: JobId=0 resumeprog exit status 1:0 [2024-11-18T10:25:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:26:02.000] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:26:02.417] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:26:02.417] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:26:20.007] debug: sched: Running job scheduler for full queue. [2024-11-18T10:26:32.417] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:26:32.417] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:27:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:28:20.003] debug: Updating partition uid access list [2024-11-18T10:28:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:28:20.008] debug: sackd_mgr_dump_state: saved state of 0 nodes [2024-11-18T10:29:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:29:22.000] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:29:22.448] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:29:22.448] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:30:20.007] debug: sched: Running job scheduler for full queue. [2024-11-18T10:31:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:32:21.000] debug: sched: Running job scheduler for full queue. [2024-11-18T10:32:42.000] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:32:42.478] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:32:42.478] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:33:12.479] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:33:12.479] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:33:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:33:20.010] debug: sackd_mgr_dump_state: saved state of 0 nodes [2024-11-18T10:34:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:35:20.007] debug: sched: Running job scheduler for full queue. [2024-11-18T10:36:01.004] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:36:01.504] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:36:01.504] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:36:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:36:31.505] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:36:31.505] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:37:21.000] debug: sched: Running job scheduler for full queue. [2024-11-18T10:38:20.008] debug: Updating partition uid access list [2024-11-18T10:38:20.008] debug: sched: Running job scheduler for full queue. [2024-11-18T10:38:20.017] debug: sackd_mgr_dump_state: saved state of 0 nodes [2024-11-18T10:39:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:39:21.003] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:39:21.530] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:39:21.530] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:39:51.531] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:39:51.531] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:40:21.000] debug: sched: Running job scheduler for full queue. [2024-11-18T10:41:20.003] debug: sched: Running job scheduler for full queue. [2024-11-18T10:41:52.003] node bibigrid-worker-wubqboa1z2kkgx0-0 not resumed by ResumeTimeout(1200) - marking down and power_save [2024-11-18T10:41:52.003] Killing JobId=1 on failed node bibigrid-worker-wubqboa1z2kkgx0-0 [2024-11-18T10:41:52.046] update_node: node bibigrid-worker-wubqboa1z2kkgx0-0 reason set to: FailedStartup [2024-11-18T10:41:52.046] power down request repeating for node bibigrid-worker-wubqboa1z2kkgx0-0 [2024-11-18T10:41:52.047] debug: sackd_mgr_dump_state: saved state of 0 nodes [2024-11-18T10:41:52.549] debug: sched/backfill: _attempt_backfill: beginning [2024-11-18T10:41:52.549] debug: sched/backfill: _attempt_backfill: no jobs to backfill [2024-11-18T10:41:52.736] _slurm_rpc_complete_job_allocation: JobId=1 error Job/step already completing or completed [2024-11-18T10:41:53.000] debug: Spawning ping agent for bibigrid-master-wubqboa1z2kkgx0 [2024-11-18T10:41:53.000] debug: sched: Running job scheduler for default depth. [2024-11-18T10:41:53.014] update_node: node bibigrid-worker-wubqboa1z2kkgx0-0 reason set to: FailedStartup [2024-11-18T10:41:53.014] update_node: node bibigrid-worker-wubqboa1z2kkgx0-0 state set to IDLE

1 1

getting slurm going
by Steven Jones 08 Dec '24

08 Dec '24

What tests can I do to prove that slurm is talking to the nodes pls? regards Steven

3 5

Non-Standard Mail Notification in Job
by Daniel Miliate 05 Dec '24

05 Dec '24

Newbie here, I'm trying to send myself an email notification with a custom body/subject for notification of important events. Is this possible? I've tried a few things in the script below. Thanks in advance and apologies if this is not how this listing works! - Daniel ---- Script ---- .... #SBATCH --mail-user= example(a)example.example #SBATCH --export=ALL #SBATCH --mail-type=ALL # Both of these work which mail which mailx EMAIL="example(a)example.example" # Attempt 1 echo "Test email body" | mail -s "Test Subject" "$EMAIL" # Attempt 2 mail -s "hello" "$EMAIL" <<EOF hello world EOF # Attempt 3 echo "Specific Information" | mail -s "SLURM Job information" $EMAIL ---- End ----

3 2

slurm not running on a warewulf node
by Steven Jones 04 Dec '24

04 Dec '24

Hi, I have set a log creation/location in slurm.conf as, SlurmdLogFile=/var/log/slurm/slurmd.log But it is 0 length. Slurm will not run, what else do I need to do to log why its failing pls? regards Steven

4 6

slurmd on a warwwulf node - not running
by Steven Jones 04 Dec '24

04 Dec '24

Hi, I have munge running on the controller and nodes fine, all tests passed. I have slurmctld running on the controller ok after checking the logs /var/spool/slurmctld was not created which I assume should have happened via the rpm install? Anyway I cant get slurmd to run on the warewulf nodes and cant find any log to check? How to fault find this? regards Steven

3 3

How can I make sure my user have only one job per node (Job array --exclusive=user,)
by Oren 03 Dec '24

03 Dec '24

Hi, I have a cluster of 20-nodes, and I want to run a jobarray on that cluster, but I want each node to get one job per node. When I do the following: #!/bin/bash #SBATCH --job-name=process_images_train # Job name #SBATCH --time=50:00:00 # Time limit hrs:min:sec #SBATCH --tasks=1 #SBATCH --cpus-per-task=4 #SBATCH --mem=50000 #SBATCH --array=0-19# 19 # Job array with 20 jobs (0 to 19) I get 10 jobs in node #1 and 10 jobs in node #20, I want a job in each node. I've tried: #SBATCH --exclusive=user Also #SBATCH --spread-job #SBATCH --distribution=cyclic Nothing changes, node#1 got 10 jobs and node#2 got 10 jobs. Thanks

2 6

multiple conf-server entries for sackd
by Brian Andrus 03 Dec '24

03 Dec '24

Not sure anyone would know, but... If you are running slurm in HA mode (multiple SlurmctldHost entries) is it possible to point sackd to more than one using the --conf-server option? So either specify --conf-server more than once, or have a comma-delimited list of them? The docs are a little light about that. Brian Andrus

1 0

sinfo not listing any partitions
by Kent L. Hanson 02 Dec '24

02 Dec '24

I am doing a new install of slurm 24.05.3 I have all the packages built and installed on headnode and compute node with the same munge.key, slurm.conf, and gres.conf file. I was able to run munge and unmunge commands to test munge successfully. Time is synced with chronyd. I can't seem to find any useful errors in the logs. For some reason when I run sinfo no nodes are listed. I just see the headers for each column. Has anyone seen this or know what a next step of troubleshooting would be? I'm new to this and not sure where to go from here. Thanks for any and all help! The odd output I am seeing [username@headnode ~] sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST (Nothing is output showing status of partition or nodes) Slurm.conf ClusterName=slurmkvasir SlurmctldHost=kadmin2 MpiDefault=none ProctrackType=proctrack/cgroup PrologFlags=contain ReturnToService=2 SlurmctldPidFile=/var/run/slurm/slurmctld.pid SlurmctldPort=6817 SlurmPidFile=/var/run/slurm/slurmd.pid SlurmdPort=6818 SlurmdSpoolDir=/var/spool/slurmd SlurmUser=slurm StateSaveLocation=/var/spool/slurmctld TaskPlugin=task/cgroup MinJobAge=600 SchedulerType=sched/backfill SelectType=select/cons_tres PriorityType=priority/multifactor AccountingStorageHost=localhost AccountingStoragePass=/var/run/munge/munge.socket.2 AccountingStorageType=accounting_storage/slurmdbd AccountingStorageTRES=gres/gpu,cpu,node JobCompType=jobcomp/none JobAcctGatherFrequency=30 JobAcctGatherType=jobacct_gather/cgroup SlurmctldDebug=info SlurmctldLogFile=/var/log/slurm/slurmctld.log SlurmdDebug=info SlurmLogFile=/var/log/slurm/slurmd.log nodeName=k[001-448] PartitionName=default Nodes=k[001-448] Default=YES MaxTime=INFINITE State=up Slurmctld.log Error: Configured MailProg is invalid Slurmctld version 24.05.3 started on cluster slurmkvasir Accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Regisetering slurmctld at port 8617 Error: read_slurm_conf: default partition not set. Revovered state of 448 nodes Down nodes: k[002-448] Recovered information about 0 jobs Revovered state of 0 reservations Read_slurm_conf: backup_controller not specified Select/cons_tres; select_p_reconfigure: select/cons_tres: reconfigure Running as primary controller Slurmd.log Error: Node configuration differs from hardware: CPUS=1:40(hw) Boards=1:1(hw) SocketsPerBoard=1:2(hw) CoresPerSocket=1:20(hw) ThreadsPerCore:1:1(hw) CPU frequency setting not configured for this node Slurmd version 24.05.3started Slurmd started on Wed, 27 Nov 2024 06:51:03 -0700 CPUS=1 Boards=1 Cores=1 Threads=1 Memory=192030 TmpDisk=95201 uptime 166740 CPUSpecList=(null) FeaturesAvail=(null) FeaturesActive=(null) Error: _forward_thread: failed to k019 (10.142.0.119:6818): Connection timed out (Above line repeated 20 or so times for different nodes.) Thanks, Kent Hanson

6 9

Slurm version 24.11 is now available
by Tim Wickberg 29 Nov '24

29 Nov '24

We are pleased to announce the availability of the Slurm 24.11 release. To highlight some new features in 24.11: - New gpu/nvidia plugin. This does not rely on any NVIDIA libraries, and will build by default on all systems. It supports basic GPU detection and management, but cannot currently identify GPU-to-GPU links, or provide usage data as these are not exposed by the kernel driver. - Add autodetected GPUs to the output from "slurmd -C". - Added new QOS-based reports to "sreport". - Revamped network I/O with the "conmgr" thread-pool model. - Added new "hostlist function" syntax for management commands and configuration files. - switch/hpe_slingshot - Added support for hardware collectives setup through the fabric manager. (Requires SlurmctldParameters=enable_stepmgr) - Added SchedulerParameters=bf_allow_magnetic_slot configuration option to allow backfill planning for magnetic reservations. - Added new "scontrol listjobs" and "liststeps" commands to complement "listpids", and provide --json/--yaml output for all three subcommands. - Allow jobs to be submitted against multiple QOSes. - Added new experimental "oracle" backfill scheduling support, which permits jobs to be delayed if the oracle function determines the reduced fragmentation of the network topology is sufficiently advantageous. - Improved responsiveness of the controller when jobs are requeued by replacing the "db_index" identifier with a slurmctld-generated unique identifier. ("SLUID") - New options to job_container/tmpfs to permit site-specific scripts to modify the namespace before user steps are launched, and to ensure all steps are completely captured within that namespace. The Slurm documentation has also been updated to the 24.11 release. (Older versions can be found in the archive, linked from the main documentation page.) Slurm can be downloaded from https://www.schedmd.com/download-slurm/ . - Tim -- Tim Wickberg Chief Technology Officer, SchedMD LLC Commercial Slurm Development and Support

1 0

Non-intiutive rank placement/CPU masking
by Ohlerich, Martin 28 Nov '24

28 Nov '24

Dear * , I've some question for understanding. Essentially, I use the following job script: ---------------------------> #!/bin/bash #SBATCH -J srun_test #SBATCH --time=0:02:00 #SBATCH --export=NONE #SBATCH --partition=test #SBATCH --nodes=2 #SBATCH -o ./%x.%j.out #SBATCH -D . srun --export=all --mpi=pmi2 --verbose --cpu-bind=verbose -n 96 --ntasks-per-node=48 --ntasks-per-socket=24 -c 2 -m block:block -B 2:56:1 /lrz/sys/tools/placement_test_2021/bin/placement-test.intel_impi ---------------------------> On a sapphire rapid with 2 sockets and 56 physical CPUs. The executable is just some MPI dummy, build with Intel Compilers and Intel MPI (although I guess that's not essential here). The related MPI environment looks as show below (1). Slurm environment is shown below under (2). Now. what I would expect intuitively is that I place here 24 ranks per socket. And here also on the even CPUs in sequence starting from CPU 0 of each socket. What I get is srun: defined options srun: -------------------- -------------------- srun: (null) : i20r01c01s[06,08] srun: cpu-bind : verbose srun: cpus-per-task : 2 srun: distribution : block:block srun: export : all srun: extra-node-info : 2:56:1 srun: jobid : 395726 srun: job-name : MGLET_srun srun: mpi : pmi2 srun: nodes : 2 srun: ntasks : 96 srun: ntasks-per-node : 48 srun: ntasks-per-socket : 24 srun: verbose : 1 srun: -------------------- -------------------- srun: end of defined options srun: jobid 395726: nodes(2):`i20r01c01s[06,08]', cpu counts: 224(x2) srun: Implicitly setting --exact, because -c/--cpus-per-task given. srun: CpuBindType=verbose,threads srun: launching StepId=395726.0 on host i20r01c01s06, 48 tasks: [0-47] srun: launching StepId=395726.0 on host i20r01c01s08, 48 tasks: [48-95] srun: topology/tree: init: topology tree plugin loaded cpu-bind=MASK - i20r01c01s06, task 1 1 [98437]: mask 0xc set cpu-bind=MASK - i20r01c01s06, task 2 2 [98438]: mask 0x30 set cpu-bind=MASK - i20r01c01s06, task 3 3 [98439]: mask 0xc0 set cpu-bind=MASK - i20r01c01s06, task 4 4 [98440]: mask 0x300 set cpu-bind=MASK - i20r01c01s06, task 5 5 [98441]: mask 0xc00 set cpu-bind=MASK - i20r01c01s06, task 6 6 [98442]: mask 0x3000 set cpu-bind=MASK - i20r01c01s06, task 7 7 [98443]: mask 0xc000 set cpu-bind=MASK - i20r01c01s06, task 8 8 [98444]: mask 0x30000 set cpu-bind=MASK - i20r01c01s06, task 9 9 [98445]: mask 0xc0000 set cpu-bind=MASK - i20r01c01s06, task 10 10 [98446]: mask 0x300000 set cpu-bind=MASK - i20r01c01s06, task 11 11 [98447]: mask 0xc00000 set cpu-bind=MASK - i20r01c01s06, task 12 12 [98448]: mask 0x3000000 set cpu-bind=MASK - i20r01c01s06, task 13 13 [98449]: mask 0xc000000 set cpu-bind=MASK - i20r01c01s06, task 14 14 [98450]: mask 0x30000000 set cpu-bind=MASK - i20r01c01s06, task 15 15 [98451]: mask 0xc0000000 set cpu-bind=MASK - i20r01c01s06, task 16 16 [98452]: mask 0x300000000 set cpu-bind=MASK - i20r01c01s06, task 17 17 [98453]: mask 0xc00000000 set cpu-bind=MASK - i20r01c01s06, task 18 18 [98454]: mask 0x3000000000 set cpu-bind=MASK - i20r01c01s06, task 19 19 [98455]: mask 0xc000000000 set cpu-bind=MASK - i20r01c01s06, task 20 20 [98456]: mask 0x30000000000 set cpu-bind=MASK - i20r01c01s06, task 21 21 [98457]: mask 0xc0000000000 set cpu-bind=MASK - i20r01c01s06, task 22 22 [98458]: mask 0x300000000000 set cpu-bind=MASK - i20r01c01s06, task 23 23 [98459]: mask 0xc00000000000 set cpu-bind=MASK - i20r01c01s06, task 24 24 [98460]: mask 0x300000000000000 set cpu-bind=MASK - i20r01c01s06, task 25 25 [98461]: mask 0xc00000000000000 set cpu-bind=MASK - i20r01c01s06, task 26 26 [98462]: mask 0x3000000000000000 set cpu-bind=MASK - i20r01c01s06, task 27 27 [98463]: mask 0xc000000000000000 set cpu-bind=MASK - i20r01c01s06, task 28 28 [98464]: mask 0x30000000000000000 set cpu-bind=MASK - i20r01c01s06, task 29 29 [98465]: mask 0xc0000000000000000 set cpu-bind=MASK - i20r01c01s06, task 30 30 [98466]: mask 0x300000000000000000 set cpu-bind=MASK - i20r01c01s06, task 31 31 [98467]: mask 0xc00000000000000000 set cpu-bind=MASK - i20r01c01s06, task 32 32 [98468]: mask 0x3000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 33 33 [98469]: mask 0xc000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 34 34 [98470]: mask 0x30000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 35 35 [98471]: mask 0xc0000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 36 36 [98472]: mask 0x300000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 37 37 [98473]: mask 0xc00000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 38 38 [98474]: mask 0x3000000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 39 39 [98475]: mask 0xc000000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 40 40 [98476]: mask 0x30000000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 41 41 [98477]: mask 0xc0000000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 42 42 [98478]: mask 0x300000000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 43 43 [98479]: mask 0xc00000000000000000000000 set cpu-bind=MASK - i20r01c01s06, task 44 44 [98480]: mask 0x3 set cpu-bind=MASK - i20r01c01s06, task 45 45 [98481]: mask 0xc set cpu-bind=MASK - i20r01c01s06, task 46 46 [98482]: mask 0x30 set srun: Node i20r01c01s06, 48 tasks started cpu-bind=MASK - i20r01c01s08, task 48 0 [179006]: mask 0x3 set cpu-bind=MASK - i20r01c01s08, task 49 1 [179007]: mask 0xc set cpu-bind=MASK - i20r01c01s08, task 50 2 [179008]: mask 0x30 set cpu-bind=MASK - i20r01c01s08, task 51 3 [179009]: mask 0xc0 set cpu-bind=MASK - i20r01c01s08, task 52 4 [179010]: mask 0x300 set cpu-bind=MASK - i20r01c01s08, task 53 5 [179011]: mask 0xc00 set cpu-bind=MASK - i20r01c01s08, task 54 6 [179012]: mask 0x3000 set cpu-bind=MASK - i20r01c01s08, task 55 7 [179013]: mask 0xc000 set cpu-bind=MASK - i20r01c01s08, task 56 8 [179014]: mask 0x30000 set cpu-bind=MASK - i20r01c01s08, task 57 9 [179015]: mask 0xc0000 set cpu-bind=MASK - i20r01c01s08, task 58 10 [179016]: mask 0x300000 set cpu-bind=MASK - i20r01c01s08, task 59 11 [179017]: mask 0xc00000 set cpu-bind=MASK - i20r01c01s08, task 60 12 [179018]: mask 0x3000000 set cpu-bind=MASK - i20r01c01s08, task 61 13 [179019]: mask 0xc000000 set cpu-bind=MASK - i20r01c01s08, task 62 14 [179020]: mask 0x30000000 set cpu-bind=MASK - i20r01c01s08, task 63 15 [179021]: mask 0xc0000000 set cpu-bind=MASK - i20r01c01s08, task 64 16 [179022]: mask 0x300000000 set cpu-bind=MASK - i20r01c01s08, task 65 17 [179023]: mask 0xc00000000 set cpu-bind=MASK - i20r01c01s08, task 66 18 [179024]: mask 0x3000000000 set cpu-bind=MASK - i20r01c01s08, task 67 19 [179025]: mask 0xc000000000 set cpu-bind=MASK - i20r01c01s08, task 68 20 [179026]: mask 0x30000000000 set cpu-bind=MASK - i20r01c01s08, task 69 21 [179027]: mask 0xc0000000000 set cpu-bind=MASK - i20r01c01s08, task 70 22 [179028]: mask 0x300000000000 set cpu-bind=MASK - i20r01c01s08, task 71 23 [179029]: mask 0xc00000000000 set cpu-bind=MASK - i20r01c01s08, task 72 24 [179030]: mask 0x300000000000000 set cpu-bind=MASK - i20r01c01s08, task 73 25 [179031]: mask 0xc00000000000000 set cpu-bind=MASK - i20r01c01s08, task 74 26 [179032]: mask 0x3000000000000000 set cpu-bind=MASK - i20r01c01s08, task 75 27 [179033]: mask 0xc000000000000000 set cpu-bind=MASK - i20r01c01s08, task 76 28 [179034]: mask 0x30000000000000000 set cpu-bind=MASK - i20r01c01s08, task 77 29 [179035]: mask 0xc0000000000000000 set cpu-bind=MASK - i20r01c01s08, task 78 30 [179036]: mask 0x300000000000000000 set cpu-bind=MASK - i20r01c01s08, task 79 31 [179037]: mask 0xc00000000000000000 set cpu-bind=MASK - i20r01c01s08, task 80 32 [179038]: mask 0x3000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 81 33 [179039]: mask 0xc000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 82 34 [179040]: mask 0x30000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 83 35 [179041]: mask 0xc0000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 84 36 [179042]: mask 0x300000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 85 37 [179043]: mask 0xc00000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 86 38 [179044]: mask 0x3000000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 87 39 [179045]: mask 0xc000000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 88 40 [179046]: mask 0x30000000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 89 41 [179047]: mask 0xc0000000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 90 42 [179048]: mask 0x300000000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 91 43 [179049]: mask 0xc00000000000000000000000 set cpu-bind=MASK - i20r01c01s08, task 92 44 [179050]: mask 0x3 set cpu-bind=MASK - i20r01c01s08, task 93 45 [179051]: mask 0xc set cpu-bind=MASK - i20r01c01s08, task 94 46 [179052]: mask 0x30 set cpu-bind=MASK - i20r01c01s08, task 95 47 [179053]: mask 0xc0 set srun: Node i20r01c01s08, 48 tasks started cpu-bind=MASK - i20r01c01s06, task 47 47 [98483]: mask 0xc0 set In words: the last 4 ranks meant for the second socket of each node are actually placed on the first socket ... So, effectively --ntasks-per-socket is then ignored? I couldn't see an obvious reason for that. Maybe I miss some important point ... or neglect some interference with Intel MPI's runtime environment (there didn't change anything in the masks when unsetting KMP_AFFINITY). I'd like also to mention that explicit placement via cpu_map does the right thing. ---------------------------> #!/bin/bash #SBATCH -J srun_test #SBATCH --time=0:02:00 #SBATCH --export=NONE #SBATCH --partition=test #SBATCH --nodes=2 #SBATCH --ntasks-per-node=48 #SBATCH -o ./%x.%j.out #SBATCH -D . srun --export=all --mpi=pmi2 --cpu-bind=map_cpu:$(seq 0 2 46 | tr '\n' ',')$(seq 56 2 102 | tr '\n' ',') /lrz/sys/tools/placement_test_2021/bin/placement-test.intel_impi ---------------------------> So, a workaround is available for me. But if I could get some illuminating hint on where my intuition failed above, I'd be very grateful. Thank you! Cheers, Martin (1) I_MPI_FILESYSTEM=on I_MPI_HYDRA_BOOTSTRAP=slurm I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS=--external-launcher I_MPI_HYDRA_BRANCH_COUNT=128 I_MPI_OFFLOAD=0 I_MPI_OFFLOAD_FAST_MEMCPY_COLL=0 I_MPI_OFFLOAD_RDMA=0 I_MPI_OFI_PROVIDER=psm3 I_MPI_ROOT=/dss/lrzsys/sys/spack/release/24.1.0/opt/x86_64/intel-oneapi-mpi/2021.11.0-gcc-w56vuor/mpi/2021.11 KMP_AFFINITY=granularity=thread,compact,1,0 (2) SLURMD_NODENAME=i20r01c01s06 SLURM_CLUSTER_NAME=sng2 SLURM_CONF=/etc/slurm/slurm.conf SLURM_CPUS_ON_NODE=224 SLURM_ECLIBR=0 SLURM_ECPLUG=1 SLURM_ERLAST=sbatch SLURM_ERSBAC=1 SLURM_GET_USER_ENV=0 SLURM_GTIDS=0 SLURM_JOBID=395726 SLURM_JOB_ACCOUNT=pr28fa SLURM_JOB_CPUS_PER_NODE=224(x2) SLURM_JOB_END_TIME=1732781080 SLURM_JOB_GID=3000114 SLURM_JOB_ID=395726 SLURM_JOB_NAME=MGLET_srun SLURM_JOB_NODELIST=i20r01c01s[06,08] SLURM_JOB_NUM_NODES=2 SLURM_JOB_PARTITION=test SLURM_JOB_QOS=test SLURM_JOB_START_TIME=1732780959 SLURM_JOB_UID=3808660 SLURM_JOB_USER=di49zop SLURM_LOCALID=0 SLURM_NNODES=2 SLURM_NODEID=0 SLURM_NODELIST=i20r01c01s[06,08] SLURM_PRIO_PROCESS=0 SLURM_PROCID=0 SLURM_SCRIPT_CONTEXT=prolog_task SLURM_SETUP_LICENSE=open source - no access restrictions SLURM_SETUP_MAINTAINER_LIST=Bader(a)lrz.de SLURM_SUBMIT_DIR=/dss/dsshome1/00/di49zop/test_mglet SLURM_SUBMIT_HOST=login26 SLURM_TASKS_PER_NODE=224(x2) SLURM_TASK_PID=98399 SLURM_TOPOLOGY_ADDR=leaf.m02r05.i20r01c01s06 SLURM_TOPOLOGY_ADDR_PATTERN=switch.switch.node

1 0

I'm very confused about priority/fairshare calculation
by Cutts, Tim 27 Nov '24

27 Nov '24

I don't know how many times I've read the docs; I keep thinking I understand it, but something is really wrong with prioritisation on our cluster, and we're struggling to understand why. The setup: 1. We have a group who submit two types of work; production jobs and research jobs. 2. We have two sacctmgr accounts for this; let's call those 'prod' and 'research'. 3. We also have some dedicated hardware that they paid for which can be used only by users associated with the prod account. Desired behaviour: 1. Usage of their dedicated hardware by production jobs should not hugely decrease the fairshare priority for research jobs in other partitions. 2. Usage of shared hardware should decrease their fairshare priority (whether by production or research jobs) 3. Memory should make a relatively small contribution to TRES usage (it's not normally the constrained resource) Our approach: Set TRESBillingWeights for cpu, memory and gres/GPU usage on shared partitions. Typically these are set to: CPU=1.0,Mem=0.25G,GRES/gpu=1.0 Set TRESBillingWeights to something small on the dedicated hardware partition, such as: CPU=0.25 Set PriorityWeightFairshare and PriorityWeightAge to values such that Fairshare dominates when jobs are young, and Age takes over if they've been pending a long time The observed behaviour: 1. production association jobs have a high priority; this is working well 2. research jobs are still getting heavily penalised in fairshare, and we don't understand why; they seem to have enormous RawUsage, largely coming from memory: Here's what I see from sshare (sensitive details removed, obviously): sshare -l -A prod, research -a -o Account,RawUsage,EffectvUsage,FairShare,LevelFS,TRESRunMins%80 | grep -v cpu=0 > ' Account RawUsage EffectvUsage FairShare LevelFS TRESRunMins -------------------- ----------- ------------- ---------- ---------- -------------------------------------------------------------------------------- prod 1587283 0.884373 0.226149 cpu=81371,mem=669457237,energy=0,node=20610,billing=100833,fs/disk=0,vmem=0,pag+ prod 1082008 0.681681 0.963786 0.366740 cpu=81281,mem=669273429,energy=0,node=20520,billing=100833,fs/disk=0,vmem=0,pag+ prod 505090 0.318202 0.964027 0.785664 cpu=90,mem=184320,energy=0,node=90,billing=0,fs/disk=0,vmem=0,pages=0,gres/gpu=+ research 1043560787 0.380577 0.121648 cpu=17181098808,mem=35196566339054,energy=0,node=4295361360,billing=25773481938+ research 146841 0.000141 0.005311 124.679238 cpu=824,mem=3375923,energy=0,node=824,billing=824,fs/disk=0,vmem=0,pages=0,gres+ research 17530141 0.016798 0.001449 1.044377 cpu=254484,mem=3379938816,energy=0,node=161907,billing=893592,fs/disk=0,vmem=0,+ research 167597 0.000161 0.005070 109.238498 cpu=7275,mem=223516160,energy=0,node=7275,billing=50931,fs/disk=0,vmem=0,pages=+ research 12712481 0.012182 0.001931 1.440166 cpu=186327,mem=95399526,energy=0,node=23290,billing=232909,fs/disk=0,vmem=0,pag+ research 11521011 0.011040 0.002173 1.589104 cpu=8167,mem=267626086,energy=0,node=8167,billing=65338,fs/disk=0,vmem=0,pages=+ research 9719735 0.009314 0.002414 1.883599 cpu=15020,mem=69214617,energy=0,node=1877,billing=3755,fs/disk=0,vmem=0,pages=0+ research 25004766 0.023961 0.001207 0.732184 cpu=590778,mem=6464600473,energy=0,node=98910,billing=2266887,fs/disk=0,vmem=0,+ research 68938740 0.066061 0.000724 0.265570 cpu=159332,mem=963064985,energy=0,node=89957,billing=192706,fs/disk=0,vmem=0,pa+ research 7359413 0.007052 0.002656 2.487710 cpu=81401,mem=583487624,energy=0,node=20350,billing=20350,fs/disk=0,vmem=0,page+ research 718714430 0.688714 0.000241 0.025473 cpu=20616,mem=337774728,energy=0,node=5154,billing=92772,fs/disk=0,vmem=0,pages+ research 1016606 0.000974 0.003863 18.009010 cpu=17179774580,mem=35184178340113,energy=0,node=4294943645,billing=25769661870+ Firstly, why are the mem TRES numbers so enormous? Secondly, what's going on with the last user, where the rawusage is tiny, but the TRESRunMins is ridiculously big? That could be messing up the whole thing. Thanks in advance for any advice (either that can help explain what I've misunderstood, or to suggestions of "there's a better way to achieve what you want") Tim -- Tim Cutts Scientific Computing Platform Lead AstraZeneca ________________________________ AstraZeneca UK Limited is a company incorporated in England and Wales with registered number:03674842 and its registered office at 1 Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0AA. This e-mail and its attachments are intended for the above named recipient only and may contain confidential and privileged information. If they have come to you in error, you must not copy or show them to anyone; instead, please reply to this e-mail, highlighting the error to the sender and then immediately delete the message. For information about how AstraZeneca UK Limited and its affiliates may process information, personal data and monitor communications, please see our privacy notice at www.astrazeneca.com<https://www.astrazeneca.com>

1 0

making a maint reservation on a specific GPU
by Paul Raines 22 Nov '24

22 Nov '24

We have a 8 GPU server in which one GPU has gone into an error state that will require a reboot to clear. I have jobs on the server running on good GPUs that will take another 3 days to complete. In the meantime, I would like short jobs to run on the good free GPUs till I reboot. I set a reservation for the time window I plan to reboot on the whole node with scontrol create reservation reservationName=rtx-01_reboot users=root starttime=2024-11-25T06:00:00 duration=720 Nodes=rtx-01 flags=maint,ignore_jobs But I would like to set a reservation on just the bad GPU (gpu_id=7) from now till 2024-11-25T06:00:00 so no job runs that will use it. Is that possible? --------------------------------------------------------------- Paul Raines http://help.nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline <https://www.massgeneralbrigham.org/complianceline> . Please note that this e-mail is not secure (encrypted). If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately. Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.

1 0

Suspending jobs and resuming
by Ratnasamy, Fritz 22 Nov '24

22 Nov '24

Hi, I am using an old slurm version 20.11.8 and we had to reboot our cluster today for maintenance. I suspended all the jobs on it with the command scontrol suspend list_job_ids and all the jobs paused and were suspended. However, when I tried to resume them after the reboot, scontrol resume did not work (it was showing in the reason column " (JobHeldAdmin)". I was able to release them with scontrol release and the jobs started to run back. However, the SLURM recorded time on it resetted (Time columns, showing 0:00 for all the jobs) though the jobs seem to have re-started from the last point before he got suspended. 1- Did I follow the right procedure to suspend, reboot and resume/release? 2- In this case, does the wall time for all the jobs goes into reset and therefore anyone with slurm admin rights will be able to have their jobs last longer than the wall time limit by suspending and resuming a job? Best, *Fritz Ratnasamy* Data Scientist Information Technology

2 1