- slurm-users - lists.schedmd.com

errors while trying to setup slurmdbd.
by Steven Jones 10 Apr '25

10 Apr '25

root@vuwunicohpcdbp1 ~]# systemctl status slurmdbd × slurmdbd.service - Slurm DBD accounting daemon Loaded: loaded (/usr/lib/systemd/system/slurmdbd.service; enabled; preset: disabled) Active: failed (Result: exit-code) since Thu 2025-04-10 10:28:52 NZST; 2min 33s ago Duration: 85ms Process: 2413 ExecStart=/usr/sbin/slurmdbd -D -s $SLURMDBD_OPTIONS (code=exited, status=1/FAILURE) Main PID: 2413 (code=exited, status=1/FAILURE) CPU: 11ms Apr 10 10:28:52 vuwunicohpcdbp1.ods.vuw.ac.nz systemd[1]: Started Slurm DBD accounting daemon. Apr 10 10:28:52 vuwunicohpcdbp1.ods.vuw.ac.nz slurmdbd[2413]: slurmdbd: accounting_storage/as_mysql: _check_mysql_concat_is_sane: MySQL server version > Apr 10 10:28:52 vuwunicohpcdbp1.ods.vuw.ac.nz slurmdbd[2413]: slurmdbd: accounting_storage/as_mysql: init: Accounting storage MYSQL plugin loaded Apr 10 10:28:52 vuwunicohpcdbp1.ods.vuw.ac.nz slurmdbd[2413]: slurmdbd: fatal: This host not configured to run SlurmDBD ((vuwunicohpcdbp1 or vuwunicohp> Apr 10 10:28:52 vuwunicohpcdbp1.ods.vuw.ac.nz systemd[1]: slurmdbd.service: Main process exited, code=exited, status=1/FAILURE Apr 10 10:28:52 vuwunicohpcdbp1.ods.vuw.ac.nz systemd[1]: slurmdbd.service: Failed with result 'exit-code'. lines 1-14/14 (END) This is a current RHEL9.5 [root@vuwunicohpcdbp1 ~]# rpm -qi mariadb Name : mariadb Epoch : 3 Version : 10.5.27 Release : 1.el9_5 Architecture: x86_64 Install Date: Fri 04 Apr 2025 11:13:14 AM NZDT Group : Unspecified Size : 18784786 License : GPLv2 and LGPLv2 Signature : RSA/SHA256, Fri 06 Dec 2024 10:47:26 PM NZDT, Key ID 199e2f91fd431d51 Source RPM : mariadb-10.5.27-1.el9_5.src.rpm Build Date : Thu 05 Dec 2024 03:22:03 PM NZDT Build Host : x86-64-04.build.eng.rdu2.redhat.com Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://mariadb.org Summary : A very fast and robust SQL database server Description : MariaDB is a community developed fork from MySQL - a multi-user, multi-threaded SQL database server. It is a client/server implementation consisting of a server daemon (mariadbd) and many different client programs and libraries. The base package contains the standard MariaDB/MySQL client programs and utilities. [root@vuwunicohpcdbp1 ~]# ========= # Example slurmdbd.conf file. # # See the slurmdbd.conf man page for more information. # # Archive info #ArchiveJobs=yes #ArchiveDir="/tmp" #ArchiveSteps=yes #ArchiveScript= #JobPurge=12 #StepPurge=1 # # Authentication info AuthType=auth/munge #AuthInfo=/var/run/munge/munge.socket.2 # # slurmDBD info DbdAddr=127.0.0.1 #DbdAddr=localhost DbdHost=vuwunicoslurmrp1.ods.vuw.ac.nz #DbdHost=localhost DbdPort=6819 SlurmUser=slurm #MessageTimeout=300 DebugLevel=verbose #DefaultQOS=normal,standby LogFile=/var/log/slurm/slurmdbd.log PidFile=/var/run/slurmdbd/slurmdbd.pid #PluginDir=/usr/lib/slurm #PrivateData=accounts,users,usage,jobs #TrackWCKey=yes # # Database info StorageType=accounting_storage/mysql #StorageHost=localhost StorageHost=127.0.0.1 #StoragePort=1234 StoragePort=3306 #StoragePort=6819 #StoragePass=xxxxx StoragePass=xxxxxx #StoragePass=aPIkaEqxLrA StorageUser=slurm StorageLoc=slurm_acct_db #ssj # ##ssj fini ============ This ran in test just fine but the slurm version is slightly newer in this case, [root@vuwunicohpcdbp1 admjonesst1]# rpm -qa |grep slurm slurm-24.11.3-1.el9.x86_64 slurm-slurmdbd-24.11.3-1.el9.x86_64 [root@vuwunicohpcdbp1 admjonesst1]# rpm -qi slurm-slurmdbd-24.11.3-1.el9.x86_64 Name : slurm-slurmdbd Version : 24.11.3 Release : 1.el9 Architecture: x86_64 Install Date: Mon 07 Apr 2025 01:58:32 PM NZST Group : System Environment/Base Size : 2959288 License : GPLv2+ Signature : (none) Source RPM : slurm-24.11.3-1.el9.src.rpm Build Date : Mon 07 Apr 2025 12:54:21 PM NZST Build Host : vuwunicoslurmp1.ods.vuw.ac.nz URL : https://slurm.schedmd.com/ Summary : Slurm database daemon Description : Slurm database daemon. Used to accept and process database RPCs and upload database changes to slurmctld daemons on each cluster [root@vuwunicohpcdbp1 admjonesst1]# regards Steven

2 2

pam error, related to accounting?
by David Bremner 09 Apr '25

09 Apr '25

Recently I enabled accounting on my tiny (1 compute node, one head node) slurm cluster. slurmdbd.conf looks like AuthType=auth/munge DbdHost=vertex DbdPort=6819 SlurmUser=slurm StorageHost=localhost StorageType=accounting_storage/mysql StorageUser=slurm StoragePass=#elided# StoragePort=3306 StorageLoc=slurm_acct_db PurgeEventAfter=30days PurgeJobAfter=30days PurgeResvAfter=30days PurgeStepAfter=30days PurgeSuspendAfter=30days Some potentially relevant parts of slurmd.conf are: UsePAM=1 ProctrackType=proctrack/cgroup SelectTypeParameters=CR_Core_Memory AccountingStorageType=accounting_storage/slurmdbd ClusterName=simplex JobCompType=jobcomp/none JobAcctGatherFrequency=30 JobAcctGatherType=jobacct_gather/cgroup Since I enabled accounting the output from every job (whether started by srun or sbatch) finishes with slurmstepd-simplex: error: pam_close_session: Cannot make/remove an entry for the specified session /etc/pamd.d/slurm has the following content auth required pam_localuser.so auth required pam_shells.so account required pam_unix.so account required pam_access.so session required pam_unix.so session optional pam_systemd.so Accounting seems to be working OK. Does anyone know what PAM related code paths could be triggered by enabling accounting? d

1 0

recommended freeIPMI version
by Heckes, Frank 09 Apr '25

09 Apr '25

Hi all, I’d like to update to SLURM version 24.11.4. I was searching for a recommendation for freeIPMI (power measurement), but couldn’t find one on the schedMD web-pages (sorry, if I overlooked it). The latest available freeIPMI is 1.6.15 (https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.15.tar.gz). Does anyone knows whether this is the best choice? Many thanks in advance for any advice. Cheers, -Frank

3 4

slurmctld HA ; backup controller doesn't schedule and start any job
by hiromasa.watanabe＠gmail.com 09 Apr '25

09 Apr '25

slurmctld HA ; backup controller doesn't schedule and start any job Hi all, I am trying a slurmctld HA configuration on two servers, using slurm version 22.05.9 of AlmaLinux 9.4. The problem is, after stopping the primary slurmctld and slurmdbd, when I submit a job with sbatch while backup slurmctld and slurmdbd are running, the job will be pending with Reason=None, and it will not be scheduled and will not start running. $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 43 cpu_multi job hpc PD 0:00 1 (None) Why won't my job start running? What should I change to get the job to start running? The slurmctld.log and configuration files are shown below. Backup's slurmctld.log： [2025-04-09T15:31:17.000] debug3: Heartbeat at 1744180276 [2025-04-09T15:31:18.000] debug3: Heartbeat at 1744180277 [2025-04-09T15:31:19.022] debug3: Heartbeat at 1744180279 [2025-04-09T15:31:19.605] debug2: Processing RPC: REQUEST_SUBMIT_BATCH_JOB from UID=1000 [2025-04-09T15:31:19.605] debug3: _set_hostname: Using auth hostname for alloc_node: compute1 [2025-04-09T15:31:19.605] debug3: JobDesc: user_id=1000 JobId=N/A partition=cpu_multi name=job [2025-04-09T15:31:19.605] debug3: cpus=2-4294967294 pn_min_cpus=1 core_spec=-1 [2025-04-09T15:31:19.605] debug3: Nodes=1-[1] Sock/Node=65534 Core/Sock=65534 Thread/Core=65534 [2025-04-09T15:31:19.605] debug3: pn_min_memory_job=18446744073709551615 pn_min_tmp_disk=-1 [2025-04-09T15:31:19.605] debug3: immediate=0 reservation=(null) [2025-04-09T15:31:19.605] debug3: features=(null) batch_features=(null) cluster_features=(null) prefer=(null) [2025-04-09T15:31:19.605] debug3: req_nodes=(null) exc_nodes=(null) [2025-04-09T15:31:19.605] debug3: time_limit=-1--1 priority=-1 contiguous=0 shared=-1 [2025-04-09T15:31:19.605] debug3: kill_on_node_fail=-1 script=#! /bin/bash #SBATCH -p cpu_multi #SBATC... [2025-04-09T15:31:19.605] debug3: argv="./twocore.sh" [2025-04-09T15:31:19.605] debug3: environment=SHELL=/bin/bash,PYENV_SHELL=bash,HISTCONTROL=ignoredups,... [2025-04-09T15:31:19.605] debug3: stdin=/dev/null stdout=/misc/home/hpc/slurmtest/twocore_%J.out stderr=(null) [2025-04-09T15:31:19.605] debug3: work_dir=/misc/home/hpc/slurmtest alloc_node:sid=compute1:281600 [2025-04-09T15:31:19.605] debug3: power_flags= [2025-04-09T15:31:19.605] debug3: resp_host=(null) alloc_resp_port=0 other_port=0 [2025-04-09T15:31:19.605] debug3: dependency=(null) account=(null) qos=(null) comment=(null) [2025-04-09T15:31:19.605] debug3: mail_type=0 mail_user=(null) nice=0 num_tasks=2 open_mode=0 overcommit=-1 acctg_freq=(null) [2025-04-09T15:31:19.605] debug3: network=(null) begin=Unknown cpus_per_task=1 requeue=-1 licenses=(null) [2025-04-09T15:31:19.605] debug3: end_time= signal=0@0 wait_all_nodes=-1 cpu_freq= [2025-04-09T15:31:19.605] debug3: ntasks_per_node=-1 ntasks_per_socket=-1 ntasks_per_core=-1 ntasks_per_tres=-1 [2025-04-09T15:31:19.605] debug3: mem_bind=0:(null) plane_size:65534 [2025-04-09T15:31:19.605] debug3: array_inx=(null) [2025-04-09T15:31:19.605] debug3: burst_buffer=(null) [2025-04-09T15:31:19.605] debug3: mcs_label=(null) [2025-04-09T15:31:19.605] debug3: deadline=Unknown [2025-04-09T15:31:19.605] debug3: bitflags=0x1a00c000 delay_boot=4294967294 [2025-04-09T15:31:19.605] debug3: assoc_mgr_fill_in_user: found correct user: hpc(1000) [2025-04-09T15:31:19.605] debug5: assoc_mgr_fill_in_assoc: looking for assoc of user=hpc(1000), acct=hpc, cluster=cluster, partition=cpu_multi [2025-04-09T15:31:19.605] debug3: assoc_mgr_fill_in_assoc: found correct association of user=hpc(1000), acct=hpc, cluster=cluster, partition=cpu_multi to assoc=16 acct=hpc [2025-04-09T15:31:19.605] debug3: found correct qos [2025-04-09T15:31:19.607] debug2: priority/multifactor: priority_p_set: initial priority for job 44 is 33 [2025-04-09T15:31:19.607] debug2: found 1 usable nodes from config containing compute1 [2025-04-09T15:31:19.607] debug2: found 1 usable nodes from config containing compute2 [2025-04-09T15:31:19.607] debug3: _pick_best_nodes: JobId=44 idle_nodes 2 share_nodes 2 [2025-04-09T15:31:19.607] debug2: select/cons_tres: select_p_job_test: evaluating JobId=44 [2025-04-09T15:31:19.607] debug2: sched: JobId=44 allocated resources: NodeList=(null) [2025-04-09T15:31:19.607] _slurm_rpc_submit_batch_job: JobId=44 InitPrio=33 usec=2490 [2025-04-09T15:31:19.608] debug3: create_mmap_buf: loaded file `/var/spool/slurm/ctld/job_state` as buf_t [2025-04-09T15:31:19.609] debug3: Writing job id 45 to header record of job_state file [2025-04-09T15:31:21.000] debug3: Heartbeat at 1744180280 [2025-04-09T15:31:21.257] debug2: _slurm_connect: failed to connect to 192.168.56.11:6817: Connection refused [2025-04-09T15:31:21.257] debug2: Error connecting slurm stream socket at 192.168.56.11:6817: Connection refused [2025-04-09T15:31:22.000] debug3: Heartbeat at 1744180282 [2025-04-09T15:31:24.000] debug3: Heartbeat at 1744180283 [2025-04-09T15:31:25.004] debug3: Heartbeat at 1744180285 [2025-04-09T15:31:27.001] debug3: Heartbeat at 1744180287 [2025-04-09T15:31:29.000] debug3: Heartbeat at 1744180288 [2025-04-09T15:31:30.000] debug3: Heartbeat at 1744180289 [2025-04-09T15:31:31.006] debug3: Heartbeat at 1744180291 [2025-04-09T15:31:32.822] debug2: _slurm_connect: failed to connect to 192.168.56.11:6817: Connection refused [2025-04-09T15:31:32.822] debug2: Error connecting slurm stream socket at 192.168.56.11:6817: Connection refused [2025-04-09T15:31:33.007] debug3: Heartbeat at 1744180293 [2025-04-09T15:31:35.000] debug3: Heartbeat at 1744180294 [2025-04-09T15:31:36.002] debug3: Heartbeat at 1744180296 [2025-04-09T15:31:36.395] debug2: select/cons_tres: select_p_job_test: evaluating JobId=43 [2025-04-09T15:31:36.395] debug2: select/cons_tres: select_p_job_test: evaluating JobId=44 [2025-04-09T15:31:38.000] debug3: Heartbeat at 1744180297 [2025-04-09T15:31:38.497] debug2: Performing purge of old job records [2025-04-09T15:31:39.000] debug3: Heartbeat at 1744180298 [2025-04-09T15:31:40.000] debug3: Heartbeat at 1744180300 [2025-04-09T15:31:40.655] debug2: Testing job time limits and checkpoints [2025-04-09T15:31:42.000] debug3: Heartbeat at 1744180301 [2025-04-09T15:31:43.000] debug3: Heartbeat at 1744180302 slurm.conf: ClusterName=cluster SlurmctldHost=gateway1 #Primary(192.168.56.11) SlurmctldHost=gateway2 #Backup(192.168.56.12) MpiDefault=pmix ProctrackType=proctrack/cgroup PrologFlags=Contain ReturnToService=0 SlurmctldPidFile=/var/run/slurm/slurmctld.pid SlurmctldPort=6817 SlurmdPidFile=/var/run/slurm/slurmd.pid SlurmdPort=6818 SlurmdSpoolDir=/var/spool/slurm/d SlurmUser=slurm StateSaveLocation=/var/spool/slurm/ctld SwitchType=switch/none TaskEpilog=/etc/slurm/taskepilog.sh TaskPlugin=task/cgroup,task/affinity TaskProlog=/etc/slurm/taskprolog.sh InactiveLimit=0 KillWait=30 MinJobAge=300 SlurmctldTimeout=10 SlurmdTimeout=300 Waittime=0 DefMemPerCPU=32 SchedulerType=sched/builtin SelectType=select/cons_tres SelectTypeParameters=CR_Core_Memory PriorityType=priority/multifactor PriorityWeightPartition=1000 AccountingStorageHost=gateway1 AccountingStorageBackupHost=gateway2 AccountingStorageType=accounting_storage/slurmdbd AccountingStoreFlags=job_comment JobCompType=jobcomp/none JobAcctGatherFrequency=30 JobAcctGatherType=jobacct_gather/cgroup SlurmctldDebug=debug5 SlurmctldLogFile=/var/log/slurm/slurmctld.log SlurmdDebug=info SlurmdLogFile=/var/log/slurm/slurmd.log NodeName=compute1 CPUs=4 Boards=1 SocketsPerBoard=1 CoresPerSocket=4 ThreadsPerCore=1 RealMemory=3900 Weight=1 NodeName=compute2 CPUs=4 Boards=1 SocketsPerBoard=1 CoresPerSocket=4 ThreadsPerCore=1 RealMemory=3900 Weight=1 PartitionName=gpu_single Nodes=ALL PriorityJobFactor=30 MaxTime=INFINITE State=UP Default=YES PartitionName=cpu_single Nodes=ALL PriorityJobFactor=10 MaxTime=INFINITE State=UP PartitionName=cpu_multi Nodes=ALL MaxTime=INFINITE State=UP slurmdbd.conf: AuthType=auth/munge DebugLevel=4 DbdHost=gateway1 DbdBackupHost=gateway2 LogFile=/var/log/slurm/slurmdbd.log PidFile=/var/run/slurm/slurmdbd.pid PurgeEventAfter=1month PurgeJobAfter=1month PurgeResvAfter=1month PurgeStepAfter=1month PurgeSuspendAfter=1month PurgeTXNAfter=1month PurgeUsageAfter=1month SlurmUser=slurm StorageType=accounting_storage/mysql StorageHost=gateway1 StoragePass=mypassword StorageUser=slurm Best regards, Hiro

1 0

Slurm version 24.11.4 is now available
by Marshall Garey 08 Apr '25

08 Apr '25

We are pleased to announce the availability of Slurm version 24.11.4. This release fixes a variety of major to minor severity bugs. Some edge cases that caused jobs to pend forever are fixed. Notable stability issues that are fixed include: * slurmctld crashing upon receiving a certain heterogeneous job submission. * slurmd crashing after a communications failure with a slurmstepd. * A variety of race conditions related to receiving and processing connections, including one that resulted in the slurmd ignoring new RPC connections. Downloads are available at https://www.schedmd.com/downloads.php . -- Marshall Garey Release Management, Support, and Development SchedMD LLC - Commercial Slurm Development and Support > -- slurmctld,slurmrestd - Avoid possible race condition that could have caused > process to crash when listener socket was closed while accepting a new > connection. > -- slurmrestd - Avoid race condition that could have resulted in address > logged for a UNIX socket to be incorrect. > -- slurmrestd - Fix parameters in OpenAPI specification for the following > endpoints to have "job_id" field: > GET /slurm/v0.0.40/jobs/state/ > GET /slurm/v0.0.41/jobs/state/ > GET /slurm/v0.0.42/jobs/state/ > GET /slurm/v0.0.43/jobs/state/ > -- slurmd - Fix tracking of thread counts that could cause incoming > connections to be ignored after burst of simultaneous incoming connections > that trigger delayed response logic. > -- Stepmgr - Avoid unnecessary SRUN_TIMEOUT forwarding to stepmgr. > -- Fix jobs being scheduled on higher weighted powered down nodes. > -- Fix how backfill scheduler filters nodes from the available nodes based on > exclusive user and mcs_label requirements. > -- acct_gather_energy/{gpu,ipmi} - Fix potential energy consumption adjustment > calculation underflow. > -- acct_gather_energy/ipmi - Fix regression introduced in 24.05.5 (which > introduced the new way of preserving energy measurements through slurmd > restarts) when EnergyIPMICalcAdjustment=yes. > -- Prevent slurmctld deadlock in the assoc mgr. > -- Fix memory leak when RestrictedCoresPerGPU is enabled. > -- Fix preemptor jobs not entering execution due to wrong calculation of > accounting policy limits. > -- Fix certain job requests that were incorrectly denied with node > configuration unavailable error. > -- slurmd - Avoid crash due when slurmd has a communications failure with > slurmstepd. > -- Fix memory leak when parsing yaml input. > -- Prevent slurmctld from showing error message about PreemptMode=GANG being a > cluster-wide option for `scontrol update part` calls that don't attempt to > modify partition PreemptMode. > -- Fix setting GANG preemption on partition when updating PreemptMode with > scontrol. > -- Fix CoreSpec and MemSpec limits not being removed from previously > configured slurmd. > -- Avoid race condition that could lead to a deadlock when slurmd, slurmstepd, > slurmctld, slurmrestd or sackd have a fatal event. > -- Fix jobs using --ntasks-per-node and --mem keep pending forever when the > requested mem divided by the number of cpus will surpass the configured > MaxMemPerCPU. > -- slurmd - Fix address logged upon new incoming RPC connection from "INVALID" > to IP address. > -- Fix memory leak when retrieving reservations. This affects scontrol, sinfo, > sview, and the following slurmrestd endpoints: > 'GET /slurm/{any_data_parser}/reservation/{reservation_name}' > 'GET /slurm/{any_data_parser}/reservations' > -- Log warning instead of debuflags=conmgr gated log when deferring new > incoming connections when number of active connections exceed > conmgr_max_connections. > -- Avoid race condition that could result in worker thread pool not activating > all threads at once after a reconfigure resulting in lower utilization of > available CPU threads until enough internal activity wakes up all threads > in the worker pool. > -- Avoid theoretical race condition that could result in new incoming RPC > socket connections being ignored after reconfigure. > -- slurmd - Avoid race condition that could result in a state where new > incoming RPC connections will always be ignored. > -- Add ReconfigFlags=KeepNodeStateFuture to restore saved FUTURE node state on > restart and reconfig instead of reverting to FUTURE state. This will be > made the default in 25.05. > -- Fix case where hetjob submit would cause slurmctld to crash. > -- Fix jobs using --cpus-per-gpu and --mem keep pending forever when the > requested mem divided by the number of cpus will surpass the configured > MaxMemPerCPU. > -- Enforce that jobs using --mem and several --*-per-* options do not violate > the MaxMemPerCPU in place. > -- slurmctld - Fix use-cases of jobs incorrectly pending held when --prefer > features are not initially satisfied. > -- slurmctld - Fix jobs incorrectly held when --prefer not satisfied in some > use-cases. > -- Ensure RestrictedCoresPerGPU and CoreSpecCount don't overlap.

1 0

slurm send email status with no details
by Oren 07 Apr '25

07 Apr '25

Hi, We set up a slurm system with email notification, this is the slurm.conf `MailProg=/usr/sbin/sendmail` But the email that I get has not status, just an empty message: [image: image.png] no subject, no info, what are we missing? Thanks~

2 1

Run a command in Slurm with all streams and signals connected to the submitting command
by Michael Milton 07 Apr '25

07 Apr '25

I'm helping with a workflow manager that needs to submit Slurm jobs. For logging and management reasons, the job (e.g. srun python) needs to be run as though it were a regular subprocess (python): - stdin, stdout and stderr for the command should be connected to process inside the job - signals sent to the command should be sent to the job process - We don't want to use the existing job allocation, if this is run from a Slurm job - The command should only terminate when the job is finished, to avoid us needing to poll Slurm We've tried: - sbatch --wait, but then SIGTERM'ing the process doesn't kill the job - salloc, but that requires a TTY process to control it (?) - salloc srun seems to mess with the terminal when it's killed, likely because of being "designed to be executed in the foreground" - Plain srun re-uses the existing Slurm allocation, and specifying resources like --mem will just request then from the current job rather than submitting a new one What is the best solution here?

2 2

Re: Run a command in Slurm with all streams and signals connected to the submitting command
by Michael Milton 05 Apr '25

05 Apr '25

Thanks Davide, It's true that srun will create an allocation if you aren't inside a job, but if you are inside a job and you request more resources than it has, then srun will just fail. This is the key issue that I want to avoid. On Sat, Apr 5, 2025 at 11:48 AM Davide DelVento <davide.quantum(a)gmail.com> wrote: > The plain srun is probably the best bet, and if you really need the thing > to be started from another slurm job (rather than the login node) you will > need to exploit the fact that > > > If necessary, srun will first create a resource allocation in which to > run the parallel job. > > AFAIK, there is no option to for the "create a resource allocation" even > if it's not necessary. But you may try to request something that is "above > and beyond" what the current allocation provides, and that might solve your > problem. > Looking at the srun man page, I could speculate that --clusters > or --cluster-constraint might help in that regard (but I am not sure). > > Have a nice weekend > > > On Fri, Apr 4, 2025 at 6:27 AM Michael Milton via slurm-users < > slurm-users(a)lists.schedmd.com> wrote: > >> I'm helping with a workflow manager that needs to submit Slurm jobs. For >> logging and management reasons, the job (e.g. srun python) needs to be run >> as though it were a regular subprocess (python): >> >> - stdin, stdout and stderr for the command should be connected to >> process inside the job >> - signals sent to the command should be sent to the job process >> - We don't want to use the existing job allocation, if this is run >> from a Slurm job >> - The command should only terminate when the job is finished, to >> avoid us needing to poll Slurm >> >> We've tried: >> >> - sbatch --wait, but then SIGTERM'ing the process doesn't kill the job >> - salloc, but that requires a TTY process to control it (?) >> - salloc srun seems to mess with the terminal when it's killed, >> likely because of being "designed to be executed in the foreground" >> - Plain srun re-uses the existing Slurm allocation, and specifying >> resources like --mem will just request then from the current job rather >> than submitting a new one >> >> What is the best solution here? >> >> -- >> slurm-users mailing list -- slurm-users(a)lists.schedmd.com >> To unsubscribe send an email to slurm-users-leave(a)lists.schedmd.com >> >

1 0

Best Way to See GPUs in Use?
by Jason Simms 02 Apr '25

02 Apr '25

Hello all, Apologies for the basic question, but is there a straightforward, best-accepted method for using Slurm to report on which GPUs are currently in use? I've done some searching and people recommend all sorts of methods, including parsing the output of nvidia-smi (seems inefficient, especially across multiple GPU nodes), as well as using other tools such as Grafana, XDMoD, etc. We do track GPUs as a resource, so I'd expect I could get at the info with sreport or something like that, but before trying to craft my own from scratch, I'm hoping someone has something working already. Ultimately I'd like to see either which cards are available by node, or the reverse (which are in use by node). I know recent versions of Slurm supposedly added tighter integration in some way with NVIDIA cards, but I can't seem to find definitive docs on what, exactly, changed or what is now possible as a result. Warmest regards, Jason -- *Jason L. Simms, Ph.D., M.P.H.* Research Computing Manager Swarthmore College Information Technology Services (610) 328-8102

3 2

slum job sumisison using different UID/GID
by navin srivastava 02 Apr '25

02 Apr '25

Hi, Can munge depend upon the UID/GID for the job submission? There is a scenario where the cluster is running with the NIS authentication mechanism. There is a login Node created which is part of LDAP and we installed the slurm to interact with slurm master. I am able to run jobs using root but for users it is not working as the UID/GID differ. Is there a way we can overcome this issue? and be able to run jobs. Rehards Navin

1 0

2025

2024

slurm-users ----- 2025 ----- April 2025 March 2025 February 2025 January 2025 ----- 2024 ----- December 2024 November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024

slurm-users