1salloc(1) Slurm Commands salloc(1)
2
6 salloc - Obtain a Slurm job allocation (a set of nodes), execute a com‐
7 mand, and then release the allocation when the command is finished.
8
11 salloc [OPTIONS(0)...] [ : [OPTIONS(N)...]] command(0) [args(0)...]
12 Option(s) define multiple jobs in a co-scheduled heterogeneous job.
14 For more details about heterogeneous jobs see the document
15 https://slurm.schedmd.com/heterogeneous_jobs.html
16
19 salloc is used to allocate a Slurm job allocation, which is a set of
20 resources (nodes), possibly with some set of constraints (e.g. number
21 of processors per node). When salloc successfully obtains the
22 requested allocation, it then runs the command specified by the user.
23 Finally, when the user specified command is complete, salloc relin‐
24 quishes the job allocation.
25 The command may be any program the user wishes. Some typical commands
27 are xterm, a shell script containing srun commands, and srun (see the
28 EXAMPLES section). If no command is specified, then the value of Sal‐
29 locDefaultCommand in slurm.conf is used. If SallocDefaultCommand is not
30 set, then salloc runs the user's default shell.
31 The following document describes the influence of various options on
33 the allocation of cpus to jobs and tasks.
34 https://slurm.schedmd.com/cpu_management.html
35 NOTE: The salloc logic includes support to save and restore the termi‐
37 nal line settings and is designed to be executed in the foreground. If
38 you need to execute salloc in the background, set its standard input to
39 some file, for example: "salloc -n16 a.out </dev/null &"
40
43 If salloc is unable to execute the user command, it will return 1 and
44 print errors to stderr. Else if success or if killed by signals HUP,
45 INT, KILL, or QUIT: it will return 0.
46
49 If provided, the command is resolved in the following order:
50 1. If command starts with ".", then path is constructed as: current
52 working directory / command
53 2. If command starts with a "/", then path is considered absolute.
55 3. If command can be resolved through PATH. See path_resolution(7).
57 4. If command is in current working directory.
59 Current working directory is the calling process working directory
61 unless the --chdir argument is passed, which will override the current
62 working directory.
63
66 -A, --account=<account>
67 Charge resources used by this job to specified account. The
68 account is an arbitrary string. The account name may be changed
69 after job submission using the scontrol command.
70 --acctg-freq
73 Define the job accounting and profiling sampling intervals.
74 This can be used to override the JobAcctGatherFrequency parame‐
75 ter in Slurm's configuration file, slurm.conf. The supported
76 format is as follows:
77 --acctg-freq=<datatype>=<interval>
79 where <datatype>=<interval> specifies the task sam‐
80 pling interval for the jobacct_gather plugin or a
81 sampling interval for a profiling type by the
82 acct_gather_profile plugin. Multiple, comma-sepa‐
83 rated <datatype>=<interval> intervals may be speci‐
84 fied. Supported datatypes are as follows:
85 task=<interval>
87 where <interval> is the task sampling inter‐
88 val in seconds for the jobacct_gather plugins
89 and for task profiling by the
90 acct_gather_profile plugin. NOTE: This fre‐
91 quency is used to monitor memory usage. If
92 memory limits are enforced the highest fre‐
93 quency a user can request is what is config‐
94 ured in the slurm.conf file. They can not
95 turn it off (=0) either.
96 energy=<interval>
98 where <interval> is the sampling interval in
99 seconds for energy profiling using the
100 acct_gather_energy plugin
101 network=<interval>
103 where <interval> is the sampling interval in
104 seconds for infiniband profiling using the
105 acct_gather_infiniband plugin.
106 filesystem=<interval>
108 where <interval> is the sampling interval in
109 seconds for filesystem profiling using the
110 acct_gather_filesystem plugin.
111 The default value for the task sampling
113 interval
114 is 30. The default value for all other intervals is 0. An
115 interval of 0 disables sampling of the specified type. If the
116 task sampling interval is 0, accounting information is collected
117 only at job termination (reducing Slurm interference with the
118 job).
119 Smaller (non-zero) values have a greater impact upon job perfor‐
120 mance, but a value of 30 seconds is not likely to be noticeable
121 for applications having less than 10,000 tasks.
122 -B --extra-node-info=<sockets[:cores[:threads]]>
125 Restrict node selection to nodes with at least the specified
126 number of sockets, cores per socket and/or threads per core.
127 NOTE: These options do not specify the resource allocation size.
128 Each value specified is considered a minimum. An asterisk (*)
129 can be used as a placeholder indicating that all available
130 resources of that type are to be utilized. Values can also be
131 specified as min-max. The individual levels can also be speci‐
132 fied in separate options if desired:
133 --sockets-per-node=<sockets>
134 --cores-per-socket=<cores>
135 --threads-per-core=<threads>
136 If task/affinity plugin is enabled, then specifying an alloca‐
137 tion in this manner also results in subsequently launched tasks
138 being bound to threads if the -B option specifies a thread
139 count, otherwise an option of cores if a core count is speci‐
140 fied, otherwise an option of sockets. If SelectType is config‐
141 ured to select/cons_res, it must have a parameter of CR_Core,
142 CR_Core_Memory, CR_Socket, or CR_Socket_Memory for this option
143 to be honored. If not specified, the scontrol show job will
144 display 'ReqS:C:T=*:*:*'. This option applies to job alloca‐
145 tions.
146 --bb=<spec>
149 Burst buffer specification. The form of the specification is
150 system dependent. Note the burst buffer may not be accessible
151 from a login node, but require that salloc spawn a shell on one
152 of it's allocated compute nodes. See the description of Sal‐
153 locDefaultCommand in the slurm.conf man page for more informa‐
154 tion about how to spawn a remote shell.
155 --bbf=<file_name>
158 Path of file containing burst buffer specification. The form of
159 the specification is system dependent. Also see --bb. Note the
160 burst buffer may not be accessible from a login node, but
161 require that salloc spawn a shell on one of it's allocated com‐
162 pute nodes. See the description of SallocDefaultCommand in the
163 slurm.conf man page for more information about how to spawn a
164 remote shell.
165 --begin=<time>
168 Defer eligibility of this job allocation until the specified
169 time.
170 Time may be of the form HH:MM:SS to run a job at a specific time
172 of day (seconds are optional). (If that time is already past,
173 the next day is assumed.) You may also specify midnight, noon,
174 fika (3 PM) or teatime (4 PM) and you can have a time-of-day
175 suffixed with AM or PM for running in the morning or the
176 evening. You can also say what day the job will be run, by
177 specifying a date of the form MMDDYY or MM/DD/YY YYYY-MM-DD.
178 Combine date and time using the following format
179 YYYY-MM-DD[THH:MM[:SS]]. You can also give times like now +
180 count time-units, where the time-units can be seconds (default),
181 minutes, hours, days, or weeks and you can tell Slurm to run the
182 job today with the keyword today and to run the job tomorrow
183 with the keyword tomorrow. The value may be changed after job
184 submission using the scontrol command. For example:
185 --begin=16:00
186 --begin=now+1hour
187 --begin=now+60 (seconds by default)
188 --begin=2010-01-20T12:34:00
189 Notes on date/time specifications:
192 - Although the 'seconds' field of the HH:MM:SS time specifica‐
193 tion is allowed by the code, note that the poll time of the
194 Slurm scheduler is not precise enough to guarantee dispatch of
195 the job on the exact second. The job will be eligible to start
196 on the next poll following the specified time. The exact poll
197 interval depends on the Slurm scheduler (e.g., 60 seconds with
198 the default sched/builtin).
199 - If no time (HH:MM:SS) is specified, the default is
200 (00:00:00).
201 - If a date is specified without a year (e.g., MM/DD) then the
202 current year is assumed, unless the combination of MM/DD and
203 HH:MM:SS has already passed for that year, in which case the
204 next year is used.
205 --bell Force salloc to ring the terminal bell when the job allocation
208 is granted (and only if stdout is a tty). By default, salloc
209 only rings the bell if the allocation is pending for more than
210 ten seconds (and only if stdout is a tty). Also see the option
211 --no-bell.
212 --cluster-constraint=<list>
215 Specifies features that a federated cluster must have to have a
216 sibling job submitted to it. Slurm will attempt to submit a sib‐
217 ling job to a cluster if it has at least one of the specified
218 features.
219 --comment=<string>
222 An arbitrary comment.
223 -C, --constraint=<list>
226 Nodes can have features assigned to them by the Slurm adminis‐
227 trator. Users can specify which of these features are required
228 by their job using the constraint option. Only nodes having
229 features matching the job constraints will be used to satisfy
230 the request. Multiple constraints may be specified with AND,
231 OR, matching OR, resource counts, etc. (some operators are not
232 supported on all system types). Supported constraint options
233 include:
234 Single Name
236 Only nodes which have the specified feature will be used.
237 For example, --constraint="intel"
238 Node Count
240 A request can specify the number of nodes needed with
241 some feature by appending an asterisk and count after the
242 feature name. For example "--nodes=16 --con‐
243 straint=graphics*4 ..." indicates that the job requires
244 16 nodes and that at least four of those nodes must have
245 the feature "graphics."
246 AND If only nodes with all of specified features will be
248 used. The ampersand is used for an AND operator. For
249 example, --constraint="intel&gpu"
250 OR If only nodes with at least one of specified features
252 will be used. The vertical bar is used for an OR opera‐
253 tor. For example, --constraint="intel|amd"
254 Matching OR
256 If only one of a set of possible options should be used
257 for all allocated nodes, then use the OR operator and
258 enclose the options within square brackets. For example:
259 "--constraint=[rack1|rack2|rack3|rack4]" might be used to
260 specify that all nodes must be allocated on a single rack
261 of the cluster, but any of those four racks can be used.
262 Multiple Counts
264 Specific counts of multiple resources may be specified by
265 using the AND operator and enclosing the options within
266 square brackets. For example: "--con‐
267 straint=[rack1*2&rack2*4]" might be used to specify that
268 two nodes must be allocated from nodes with the feature
269 of "rack1" and four nodes must be allocated from nodes
270 with the feature "rack2".
271 NOTE: This construct does not support multiple Intel KNL
273 NUMA or MCDRAM modes. For example, while "--con‐
274 straint=[(knl&quad)*2&(knl&hemi)*4]" is not supported,
275 "--constraint=[haswell*2&(knl&hemi)*4]" is supported.
276 Specification of multiple KNL modes requires the use of a
277 heterogeneous job.
278 Parenthesis
281 Parenthesis can be used to group like node features
282 together. For example "--con‐
283 straint=[(knl&snc4&flat)*4&haswell*1]" might be used to
284 specify that four nodes with the features "knl", "snc4"
285 and "flat" plus one node with the feature "haswell" are
286 required. All options within parenthesis should be
287 grouped with AND (e.g. "&") operands.
288 --contiguous
291 If set, then the allocated nodes must form a contiguous set.
292 Not honored with the topology/tree or topology/3d_torus plugins,
293 both of which can modify the node ordering.
294 --cores-per-socket=<cores>
297 Restrict node selection to nodes with at least the specified
298 number of cores per socket. See additional information under -B
299 option above when task/affinity plugin is enabled.
300 --cpu-freq =<p1[-p2[:p3]]>
303 Request that job steps initiated by srun commands inside this
305 allocation be run at some requested frequency if possible, on
306 the CPUs selected for the step on the compute node(s).
307 p1 can be [#### | low | medium | high | highm1] which will set
309 the frequency scaling_speed to the corresponding value, and set
310 the frequency scaling_governor to UserSpace. See below for defi‐
311 nition of the values.
312 p1 can be [Conservative | OnDemand | Performance | PowerSave]
314 which will set the scaling_governor to the corresponding value.
315 The governor has to be in the list set by the slurm.conf option
316 CpuFreqGovernors.
317 When p2 is present, p1 will be the minimum scaling frequency and
319 p2 will be the maximum scaling frequency.
320 p2 can be [#### | medium | high | highm1] p2 must be greater
322 than p1.
323 p3 can be [Conservative | OnDemand | Performance | PowerSave |
325 UserSpace] which will set the governor to the corresponding
326 value.
327 If p3 is UserSpace, the frequency scaling_speed will be set by a
329 power or energy aware scheduling strategy to a value between p1
330 and p2 that lets the job run within the site's power goal. The
331 job may be delayed if p1 is higher than a frequency that allows
332 the job to run within the goal.
333 If the current frequency is < min, it will be set to min. Like‐
335 wise, if the current frequency is > max, it will be set to max.
336 Acceptable values at present include:
338 #### frequency in kilohertz
340 Low the lowest available frequency
342 High the highest available frequency
344 HighM1 (high minus one) will select the next highest
346 available frequency
347 Medium attempts to set a frequency in the middle of the
349 available range
350 Conservative attempts to use the Conservative CPU governor
352 OnDemand attempts to use the OnDemand CPU governor (the
354 default value)
355 Performance attempts to use the Performance CPU governor
357 PowerSave attempts to use the PowerSave CPU governor
359 UserSpace attempts to use the UserSpace CPU governor
361 The following informational environment variable is set
364 in the job
365 step when --cpu-freq option is requested.
366 SLURM_CPU_FREQ_REQ
367 This environment variable can also be used to supply the value
369 for the CPU frequency request if it is set when the 'srun' com‐
370 mand is issued. The --cpu-freq on the command line will over‐
371 ride the environment variable value. The form on the environ‐
372 ment variable is the same as the command line. See the ENVIRON‐
373 MENT VARIABLES section for a description of the
374 SLURM_CPU_FREQ_REQ variable.
375 NOTE: This parameter is treated as a request, not a requirement.
377 If the job step's node does not support setting the CPU fre‐
378 quency, or the requested value is outside the bounds of the
379 legal frequencies, an error is logged, but the job step is
380 allowed to continue.
381 NOTE: Setting the frequency for just the CPUs of the job step
383 implies that the tasks are confined to those CPUs. If task con‐
384 finement (i.e., TaskPlugin=task/affinity or TaskPlu‐
385 gin=task/cgroup with the "ConstrainCores" option) is not config‐
386 ured, this parameter is ignored.
387 NOTE: When the step completes, the frequency and governor of
389 each selected CPU is reset to the previous values.
390 NOTE: When submitting jobs with the --cpu-freq option with lin‐
392 uxproc as the ProctrackType can cause jobs to run too quickly
393 before Accounting is able to poll for job information. As a
394 result not all of accounting information will be present.
395 --cpus-per-gpu=<ncpus>
398 Advise Slurm that ensuing job steps will require ncpus proces‐
399 sors per allocated GPU. Requires the --gpus option. Not com‐
400 patible with the --cpus-per-task option.
401 -c, --cpus-per-task=<ncpus>
404 Advise Slurm that ensuing job steps will require ncpus proces‐
405 sors per task. By default Slurm will allocate one processor per
406 task.
407 For instance, consider an application that has 4 tasks, each
409 requiring 3 processors. If our cluster is comprised of
410 quad-processors nodes and we simply ask for 12 processors, the
411 controller might give us only 3 nodes. However, by using the
412 --cpus-per-task=3 options, the controller knows that each task
413 requires 3 processors on the same node, and the controller will
414 grant an allocation of 4 nodes, one for each of the 4 tasks.
415 --deadline=<OPT>
418 remove the job if no ending is possible before this deadline
419 (start > (deadline - time[-min])). Default is no deadline.
420 Valid time formats are:
421 HH:MM[:SS] [AM|PM]
422 MMDD[YY] or MM/DD[/YY] or MM.DD[.YY]
423 MM/DD[/YY]-HH:MM[:SS]
424 YYYY-MM-DD[THH:MM[:SS]]]
425 --delay-boot=<minutes>
428 Do not reboot nodes in order to satisfied this job's feature
429 specification if the job has been eligible to run for less than
430 this time period. If the job has waited for less than the spec‐
431 ified period, it will use only nodes which already have the
432 specified features. The argument is in units of minutes. A
433 default value may be set by a system administrator using the
434 delay_boot option of the SchedulerParameters configuration
435 parameter in the slurm.conf file, otherwise the default value is
436 zero (no delay).
437 -d, --dependency=<dependency_list>
440 Defer the start of this job until the specified dependencies
441 have been satisfied completed. <dependency_list> is of the form
442 <type:job_id[:job_id][,type:job_id[:job_id]]> or
443 <type:job_id[:job_id][?type:job_id[:job_id]]>. All dependencies
444 must be satisfied if the "," separator is used. Any dependency
445 may be satisfied if the "?" separator is used. Many jobs can
446 share the same dependency and these jobs may even belong to dif‐
447 ferent users. The value may be changed after job submission
448 using the scontrol command. Once a job dependency fails due to
449 the termination state of a preceding job, the dependent job will
450 never be run, even if the preceding job is requeued and has a
451 different termination state in a subsequent execution.
452 after:job_id[:jobid...]
454 This job can begin execution after the specified jobs
455 have begun execution.
456 afterany:job_id[:jobid...]
458 This job can begin execution after the specified jobs
459 have terminated.
460 afterburstbuffer:job_id[:jobid...]
462 This job can begin execution after the specified jobs
463 have terminated and any associated burst buffer stage out
464 operations have completed.
465 aftercorr:job_id[:jobid...]
467 A task of this job array can begin execution after the
468 corresponding task ID in the specified job has completed
469 successfully (ran to completion with an exit code of
470 zero).
471 afternotok:job_id[:jobid...]
473 This job can begin execution after the specified jobs
474 have terminated in some failed state (non-zero exit code,
475 node failure, timed out, etc).
476 afterok:job_id[:jobid...]
478 This job can begin execution after the specified jobs
479 have successfully executed (ran to completion with an
480 exit code of zero).
481 expand:job_id
483 Resources allocated to this job should be used to expand
484 the specified job. The job to expand must share the same
485 QOS (Quality of Service) and partition. Gang scheduling
486 of resources in the partition is also not supported.
487 singleton
489 This job can begin execution after any previously
490 launched jobs sharing the same job name and user have
491 terminated. In other words, only one job by that name
492 and owned by that user can be running or suspended at any
493 point in time.
494 -D, --chdir=<path>
497 Change directory to path before beginning execution. The path
498 can be specified as full path or relative path to the directory
499 where the command is executed.
500 --exclusive[=user|mcs]
503 The job allocation can not share nodes with other running jobs
504 (or just other users with the "=user" option or with the "=mcs"
505 option). The default shared/exclusive behavior depends on sys‐
506 tem configuration and the partition's OverSubscribe option takes
507 precedence over the job's option.
508 -F, --nodefile=<node file>
511 Much like --nodelist, but the list is contained in a file of
512 name node file. The node names of the list may also span multi‐
513 ple lines in the file. Duplicate node names in the file will
514 be ignored. The order of the node names in the list is not
515 important; the node names will be sorted by Slurm.
516 --get-user-env[=timeout][mode]
519 This option will load login environment variables for the user
520 specified in the --uid option. The environment variables are
521 retrieved by running something of this sort "su - <username> -c
522 /usr/bin/env" and parsing the output. Be aware that any envi‐
523 ronment variables already set in salloc's environment will take
524 precedence over any environment variables in the user's login
525 environment. The optional timeout value is in seconds. Default
526 value is 3 seconds. The optional mode value control the "su"
527 options. With a mode value of "S", "su" is executed without the
528 "-" option. With a mode value of "L", "su" is executed with the
529 "-" option, replicating the login environment. If mode not
530 specified, the mode established at Slurm build time is used.
531 Example of use include "--get-user-env", "--get-user-env=10"
532 "--get-user-env=10L", and "--get-user-env=S". NOTE: This option
533 only works if the caller has an effective uid of "root". This
534 option was originally created for use by Moab.
535 --gid=<group>
538 Submit the job with the specified group's group access permis‐
539 sions. group may be the group name or the numerical group ID.
540 In the default Slurm configuration, this option is only valid
541 when used by the user root.
542 -G, --gpus=[<type>:]<number>
545 Specify the total number of GPUs required for the job. An
546 optional GPU type specification can be supplied. For example
547 "--gpus=volta:3". Multiple options can be requested in a comma
548 separated list, for example: "--gpus=volta:3,kepler:1". See
549 also the --gpus-per-node, --gpus-per-socket and --gpus-per-task
550 options.
551 --gpu-bind=<type>
554 Bind tasks to specific GPUs. By default every spawned task can
555 access every GPU allocated to the job.
556 Supported type options:
558 closest Bind each task to the GPU(s) which are closest. In a
560 NUMA environment, each task may be bound to more than
561 one GPU (i.e. all GPUs in that NUMA environment).
562 map_gpu:<list>
564 Bind by setting GPU masks on tasks (or ranks) as spec‐
565 ified where <list> is
566 <gpu_id_for_task_0>,<gpu_id_for_task_1>,... GPU IDs
567 are interpreted as decimal values unless they are pre‐
568 ceded with '0x' in which case they interpreted as
569 hexadecimal values. If the number of tasks (or ranks)
570 exceeds the number of elements in this list, elements
571 in the list will be reused as needed starting from the
572 beginning of the list. To simplify support for large
573 task counts, the lists may follow a map with an aster‐
574 isk and repetition count. For example
575 "map_cpu:0*4,1*4". Not supported unless the entire
576 node is allocated to the job.
577 mask_gpu:<list>
579 Bind by setting GPU masks on tasks (or ranks) as spec‐
580 ified where <list> is
581 <gpu_mask_for_task_0>,<gpu_mask_for_task_1>,... The
582 mapping is specified for a node and identical mapping
583 is applied to the tasks on every node (i.e. the lowest
584 task ID on each node is mapped to the first mask spec‐
585 ified in the list, etc.). GPU masks are always inter‐
586 preted as hexadecimal values but can be preceded with
587 an optional '0x'. Not supported unless the entire node
588 is allocated to the job. To simplify support for large
589 task counts, the lists may follow a map with an aster‐
590 isk and repetition count. For example
591 "mask_gpu:0x0f*4,0xf0*4". Not supported unless the
592 entire node is allocated to the job.
593 --gpu-freq=[<type]=value>[,<type=value>][,verbose]
596 Request that GPUs allocated to the job are configured with spe‐
597 cific frequency values. This option can be used to indepen‐
598 dently configure the GPU and its memory frequencies. After the
599 job is completed, the frequencies of all affected GPUs will be
600 reset to the highest possible values. In some cases, system
601 power caps may override the requested values. The field type
602 can be "memory". If type is not specified, the GPU frequency is
603 implied. The value field can either be "low", "medium", "high",
604 "highm1" or a numeric value in megahertz (MHz). If the speci‐
605 fied numeric value is not possible, a value as close as possible
606 will be used. See below for definition of the values. The ver‐
607 bose option causes current GPU frequency information to be
608 logged. Examples of use include "--gpu-freq=medium,memory=high"
609 and "--gpu-freq=450".
610 Supported value definitions:
612 low the lowest available frequency.
614 medium attempts to set a frequency in the middle of the
616 available range.
617 high the highest available frequency.
619 highm1 (high minus one) will select the next highest avail‐
621 able frequency.
622 --gpus-per-node=[<type>:]<number>
625 Specify the number of GPUs required for the job on each node
626 included in the job's resource allocation. An optional GPU type
627 specification can be supplied. For example
628 "--gpus-per-node=volta:3". Multiple options can be requested in
629 a comma separated list, for example:
630 "--gpus-per-node=volta:3,kepler:1". See also the --gpus,
631 --gpus-per-socket and --gpus-per-task options.
632 --gpus-per-socket=[<type>:]<number>
635 Specify the number of GPUs required for the job on each socket
636 included in the job's resource allocation. An optional GPU type
637 specification can be supplied. For example
638 "--gpus-per-socket=volta:3". Multiple options can be requested
639 in a comma separated list, for example:
640 "--gpus-per-socket=volta:3,kepler:1". Requires job to specify a
641 sockets per node count ( --sockets-per-node). See also the
642 --gpus, --gpus-per-node and --gpus-per-task options.
643 --gpus-per-task=[<type>:]<number>
646 Specify the number of GPUs required for the job on each task to
647 be spawned in the job's resource allocation. An optional GPU
648 type specification can be supplied. This option requires the
649 specification of a task count. For example
650 "--gpus-per-task=volta:1". Multiple options can be requested in
651 a comma separated list, for example:
652 "--gpus-per-task=volta:3,kepler:1". Requires job to specify a
653 task count (--nodes). See also the --gpus, --gpus-per-socket
654 and --gpus-per-node options.
655 --gres=<list>
658 Specifies a comma delimited list of generic consumable
659 resources. The format of each entry on the list is
660 "name[[:type]:count]". The name is that of the consumable
661 resource. The count is the number of those resources with a
662 default value of 1. The count can have a suffix of "k" or "K"
663 (multiple of 1024), "m" or "M" (multiple of 1024 x 1024), "g" or
664 "G" (multiple of 1024 x 1024 x 1024), "t" or "T" (multiple of
665 1024 x 1024 x 1024 x 1024), "p" or "P" (multiple of 1024 x 1024
666 x 1024 x 1024 x 1024). The specified resources will be allo‐
667 cated to the job on each node. The available generic consumable
668 resources is configurable by the system administrator. A list
669 of available generic consumable resources will be printed and
670 the command will exit if the option argument is "help". Exam‐
671 ples of use include "--gres=gpu:2,mic:1", "--gres=gpu:kepler:2",
672 and "--gres=help".
673 --gres-flags=<type>
676 Specify generic resource task binding options.
677 disable-binding
679 Disable filtering of CPUs with respect to generic
680 resource locality. This option is currently required to
681 use more CPUs than are bound to a GRES (i.e. if a GPU is
682 bound to the CPUs on one socket, but resources on more
683 than one socket are required to run the job). This
684 option may permit a job to be allocated resources sooner
685 than otherwise possible, but may result in lower job per‐
686 formance.
687 enforce-binding
689 The only CPUs available to the job will be those bound to
690 the selected GRES (i.e. the CPUs identified in the
691 gres.conf file will be strictly enforced). This option
692 may result in delayed initiation of a job. For example a
693 job requiring two GPUs and one CPU will be delayed until
694 both GPUs on a single socket are available rather than
695 using GPUs bound to separate sockets, however the appli‐
696 cation performance may be improved due to improved commu‐
697 nication speed. Requires the node to be configured with
698 more than one socket and resource filtering will be per‐
699 formed on a per-socket basis.
700 -H, --hold
703 Specify the job is to be submitted in a held state (priority of
704 zero). A held job can now be released using scontrol to reset
705 its priority (e.g. "scontrol release <job_id>").
706 -h, --help
709 Display help information and exit.
710 --hint=<type>
713 Bind tasks according to application hints.
714 compute_bound
716 Select settings for compute bound applications: use all
717 cores in each socket, one thread per core.
718 memory_bound
720 Select settings for memory bound applications: use only
721 one core in each socket, one thread per core.
722 [no]multithread
724 [don't] use extra threads with in-core multi-threading
725 which can benefit communication intensive applications.
726 Only supported with the task/affinity plugin.
727 help show this help message
729 -I, --immediate[=<seconds>]
732 exit if resources are not available within the time period spec‐
733 ified. If no argument is given, resources must be available
734 immediately for the request to succeed. By default, --immediate
735 is off, and the command will block until resources become avail‐
736 able. Since this option's argument is optional, for proper pars‐
737 ing the single letter option must be followed immediately with
738 the value and not include a space between them. For example
739 "-I60" and not "-I 60".
740 -J, --job-name=<jobname>
743 Specify a name for the job allocation. The specified name will
744 appear along with the job id number when querying running jobs
745 on the system. The default job name is the name of the "com‐
746 mand" specified on the command line.
747 -K, --kill-command[=signal]
750 salloc always runs a user-specified command once the allocation
751 is granted. salloc will wait indefinitely for that command to
752 exit. If you specify the --kill-command option salloc will send
753 a signal to your command any time that the Slurm controller
754 tells salloc that its job allocation has been revoked. The job
755 allocation can be revoked for a couple of reasons: someone used
756 scancel to revoke the allocation, or the allocation reached its
757 time limit. If you do not specify a signal name or number and
758 Slurm is configured to signal the spawned command at job termi‐
759 nation, the default signal is SIGHUP for interactive and SIGTERM
760 for non-interactive sessions. Since this option's argument is
761 optional, for proper parsing the single letter option must be
762 followed immediately with the value and not include a space
763 between them. For example "-K1" and not "-K 1".
764 -k, --no-kill [=off]
767 Do not automatically terminate a job if one of the nodes it has
768 been allocated fails. The user will assume the responsibilities
769 for fault-tolerance should a node fail. When there is a node
770 failure, any active job steps (usually MPI jobs) on that node
771 will almost certainly suffer a fatal error, but with --no-kill,
772 the job allocation will not be revoked so the user may launch
773 new job steps on the remaining nodes in their allocation.
774 Specify an optional argument of "off" disable the effect of the
776 SALLOC_NO_KILL environment variable.
777 By default Slurm terminates the entire job allocation if any
779 node fails in its range of allocated nodes.
780 -L, --licenses=<license>
783 Specification of licenses (or other resources available on all
784 nodes of the cluster) which must be allocated to this job.
785 License names can be followed by a colon and count (the default
786 count is one). Multiple license names should be comma separated
787 (e.g. "--licenses=foo:4,bar").
788 -M, --clusters=<string>
791 Clusters to issue commands to. Multiple cluster names may be
792 comma separated. The job will be submitted to the one cluster
793 providing the earliest expected job initiation time. The default
794 value is the current cluster. A value of 'all' will query to run
795 on all clusters. Note that the SlurmDBD must be up for this
796 option to work properly.
797 -m, --distribution=
800 arbitrary|<block|cyclic|plane=<options>[:block|cyclic|fcyclic]>
801 Specify alternate distribution methods for remote processes. In
803 salloc, this only sets environment variables that will be used
804 by subsequent srun requests. This option controls the assign‐
805 ment of tasks to the nodes on which resources have been allo‐
806 cated, and the distribution of those resources to tasks for
807 binding (task affinity). The first distribution method (before
808 the ":") controls the distribution of resources across nodes.
809 The optional second distribution method (after the ":") controls
810 the distribution of resources across sockets within a node.
811 Note that with select/cons_res, the number of cpus allocated on
812 each socket and node may be different. Refer to
813 https://slurm.schedmd.com/mc_support.html for more information
814 on resource allocation, assignment of tasks to nodes, and bind‐
815 ing of tasks to CPUs.
816 First distribution method:
818 block The block distribution method will distribute tasks to a
820 node such that consecutive tasks share a node. For exam‐
821 ple, consider an allocation of three nodes each with two
822 cpus. A four-task block distribution request will dis‐
823 tribute those tasks to the nodes with tasks one and two
824 on the first node, task three on the second node, and
825 task four on the third node. Block distribution is the
826 default behavior if the number of tasks exceeds the num‐
827 ber of allocated nodes.
828 cyclic The cyclic distribution method will distribute tasks to a
830 node such that consecutive tasks are distributed over
831 consecutive nodes (in a round-robin fashion). For exam‐
832 ple, consider an allocation of three nodes each with two
833 cpus. A four-task cyclic distribution request will dis‐
834 tribute those tasks to the nodes with tasks one and four
835 on the first node, task two on the second node, and task
836 three on the third node. Note that when SelectType is
837 select/cons_res, the same number of CPUs may not be allo‐
838 cated on each node. Task distribution will be round-robin
839 among all the nodes with CPUs yet to be assigned to
840 tasks. Cyclic distribution is the default behavior if
841 the number of tasks is no larger than the number of allo‐
842 cated nodes.
843 plane The tasks are distributed in blocks of a specified size.
845 The options include a number representing the size of the
846 task block. This is followed by an optional specifica‐
847 tion of the task distribution scheme within a block of
848 tasks and between the blocks of tasks. The number of
849 tasks distributed to each node is the same as for cyclic
850 distribution, but the taskids assigned to each node
851 depend on the plane size. For more details (including
852 examples and diagrams), please see
853 https://slurm.schedmd.com/mc_support.html
854 and
855 https://slurm.schedmd.com/dist_plane.html
856 arbitrary
858 The arbitrary method of distribution will allocate pro‐
859 cesses in-order as listed in file designated by the envi‐
860 ronment variable SLURM_HOSTFILE. If this variable is
861 listed it will over ride any other method specified. If
862 not set the method will default to block. Inside the
863 hostfile must contain at minimum the number of hosts
864 requested and be one per line or comma separated. If
865 specifying a task count (-n, --ntasks=<number>), your
866 tasks will be laid out on the nodes in the order of the
867 file.
868 NOTE: The arbitrary distribution option on a job alloca‐
869 tion only controls the nodes to be allocated to the job
870 and not the allocation of CPUs on those nodes. This
871 option is meant primarily to control a job step's task
872 layout in an existing job allocation for the srun com‐
873 mand.
874 Second distribution method:
877 block The block distribution method will distribute tasks to
879 sockets such that consecutive tasks share a socket.
880 cyclic The cyclic distribution method will distribute tasks to
882 sockets such that consecutive tasks are distributed over
883 consecutive sockets (in a round-robin fashion). Tasks
884 requiring more than one CPU will have all of those CPUs
885 allocated on a single socket if possible.
886 fcyclic
888 The fcyclic distribution method will distribute tasks to
889 sockets such that consecutive tasks are distributed over
890 consecutive sockets (in a round-robin fashion). Tasks
891 requiring more than one CPU will have each CPUs allocated
892 in a cyclic fashion across sockets.
893 --mail-type=<type>
896 Notify user by email when certain event types occur. Valid type
897 values are NONE, BEGIN, END, FAIL, REQUEUE, ALL (equivalent to
898 BEGIN, END, FAIL, REQUEUE, and STAGE_OUT), STAGE_OUT (burst buf‐
899 fer stage out and teardown completed), TIME_LIMIT, TIME_LIMIT_90
900 (reached 90 percent of time limit), TIME_LIMIT_80 (reached 80
901 percent of time limit), and TIME_LIMIT_50 (reached 50 percent of
902 time limit). Multiple type values may be specified in a comma
903 separated list. The user to be notified is indicated with
904 --mail-user.
905 --mail-user=<user>
908 User to receive email notification of state changes as defined
909 by --mail-type. The default value is the submitting user.
910 --mcs-label=<mcs>
913 Used only when the mcs/group plugin is enabled. This parameter
914 is a group among the groups of the user. Default value is cal‐
915 culated by the Plugin mcs if it's enabled.
916 --mem=<size[units]>
919 Specify the real memory required per node. Default units are
920 megabytes unless the SchedulerParameters configuration parameter
921 includes the "default_gbytes" option for gigabytes. Different
922 units can be specified using the suffix [K|M|G|T]. Default
923 value is DefMemPerNode and the maximum value is MaxMemPerNode.
924 If configured, both of parameters can be seen using the scontrol
925 show config command. This parameter would generally be used if
926 whole nodes are allocated to jobs (SelectType=select/linear).
927 Also see --mem-per-cpu and --mem-per-gpu. The --mem,
928 --mem-per-cpu and --mem-per-gpu options are mutually exclusive.
929 If --mem, --mem-per-cpu or --mem-per-gpu are specified as com‐
930 mand line arguments, then they will take precedence over the
931 environment.
932 NOTE: A memory size specification of zero is treated as a spe‐
934 cial case and grants the job access to all of the memory on each
935 node. If the job is allocated multiple nodes in a heterogeneous
936 cluster, the memory limit on each node will be that of the node
937 in the allocation with the smallest memory size (same limit will
938 apply to every node in the job's allocation).
939 NOTE: Enforcement of memory limits currently relies upon the
941 task/cgroup plugin or enabling of accounting, which samples mem‐
942 ory use on a periodic basis (data need not be stored, just col‐
943 lected). In both cases memory use is based upon the job's Resi‐
944 dent Set Size (RSS). A task may exceed the memory limit until
945 the next periodic accounting sample.
946 --mem-per-cpu=<size[units]>
949 Minimum memory required per allocated CPU. Default units are
950 megabytes unless the SchedulerParameters configuration parameter
951 includes the "default_gbytes" option for gigabytes. Different
952 units can be specified using the suffix [K|M|G|T]. Default
953 value is DefMemPerCPU and the maximum value is MaxMemPerCPU (see
954 exception below). If configured, both of parameters can be seen
955 using the scontrol show config command. Note that if the job's
956 --mem-per-cpu value exceeds the configured MaxMemPerCPU, then
957 the user's limit will be treated as a memory limit per task;
958 --mem-per-cpu will be reduced to a value no larger than MaxMem‐
959 PerCPU; --cpus-per-task will be set and the value of
960 --cpus-per-task multiplied by the new --mem-per-cpu value will
961 equal the original --mem-per-cpu value specified by the user.
962 This parameter would generally be used if individual processors
963 are allocated to jobs (SelectType=select/cons_res). If
964 resources are allocated by the core, socket or whole nodes; the
965 number of CPUs allocated to a job may be higher than the task
966 count and the value of --mem-per-cpu should be adjusted accord‐
967 ingly. Also see --mem and --mem-per-gpu. The --mem,
968 --mem-per-cpu and --mem-per-gpu options are mutually exclusive.
969 NOTE:If the final amount of memory requested by job (eg.: when
971 --mem-per-cpu use with --exclusive option) can't be satisfied by
972 any of nodes configured in the partition, the job will be
973 rejected.
974 --mem-per-gpu=<size[units]>
977 Minimum memory required per allocated GPU. Default units are
978 megabytes unless the SchedulerParameters configuration parameter
979 includes the "default_gbytes" option for gigabytes. Different
980 units can be specified using the suffix [K|M|G|T]. Default
981 value is DefMemPerGPU and is available on both a global and per
982 partition basis. If configured, the parameters can be seen
983 using the scontrol show config and scontrol show partition com‐
984 mands. Also see --mem. The --mem, --mem-per-cpu and
985 --mem-per-gpu options are mutually exclusive.
986 --mem-bind=[{quiet,verbose},]type
989 Bind tasks to memory. Used only when the task/affinity plugin is
990 enabled and the NUMA memory functions are available. Note that
991 the resolution of CPU and memory binding may differ on some
992 architectures. For example, CPU binding may be performed at the
993 level of the cores within a processor while memory binding will
994 be performed at the level of nodes, where the definition of
995 "nodes" may differ from system to system. By default no memory
996 binding is performed; any task using any CPU can use any memory.
997 This option is typically used to ensure that each task is bound
998 to the memory closest to it's assigned CPU. The use of any type
999 other than "none" or "local" is not recommended. If you want
1000 greater control, try running a simple test code with the options
1001 "--cpu-bind=verbose,none --mem-bind=verbose,none" to determine
1002 the specific configuration.
1003 NOTE: To have Slurm always report on the selected memory binding
1005 for all commands executed in a shell, you can enable verbose
1006 mode by setting the SLURM_MEM_BIND environment variable value to
1007 "verbose".
1008 The following informational environment variables are set when
1010 --mem-bind is in use:
1011 SLURM_MEM_BIND_LIST
1013 SLURM_MEM_BIND_PREFER
1014 SLURM_MEM_BIND_SORT
1015 SLURM_MEM_BIND_TYPE
1016 SLURM_MEM_BIND_VERBOSE
1017 See the ENVIRONMENT VARIABLES section for a more detailed
1019 description of the individual SLURM_MEM_BIND* variables.
1020 Supported options include:
1022 help show this help message
1024 local Use memory local to the processor in use
1026 map_mem:<list>
1028 Bind by setting memory masks on tasks (or ranks) as spec‐
1029 ified where <list> is
1030 <numa_id_for_task_0>,<numa_id_for_task_1>,... The map‐
1031 ping is specified for a node and identical mapping is
1032 applied to the tasks on every node (i.e. the lowest task
1033 ID on each node is mapped to the first ID specified in
1034 the list, etc.). NUMA IDs are interpreted as decimal
1035 values unless they are preceded with '0x' in which case
1036 they interpreted as hexadecimal values. If the number of
1037 tasks (or ranks) exceeds the number of elements in this
1038 list, elements in the list will be reused as needed
1039 starting from the beginning of the list. To simplify
1040 support for large task counts, the lists may follow a map
1041 with an asterisk and repetition count For example
1042 "map_mem:0x0f*4,0xf0*4". Not supported unless the entire
1043 node is allocated to the job.
1044 mask_mem:<list>
1046 Bind by setting memory masks on tasks (or ranks) as spec‐
1047 ified where <list> is
1048 <numa_mask_for_task_0>,<numa_mask_for_task_1>,... The
1049 mapping is specified for a node and identical mapping is
1050 applied to the tasks on every node (i.e. the lowest task
1051 ID on each node is mapped to the first mask specified in
1052 the list, etc.). NUMA masks are always interpreted as
1053 hexadecimal values. Note that masks must be preceded
1054 with a '0x' if they don't begin with [0-9] so they are
1055 seen as numerical values. If the number of tasks (or
1056 ranks) exceeds the number of elements in this list, ele‐
1057 ments in the list will be reused as needed starting from
1058 the beginning of the list. To simplify support for large
1059 task counts, the lists may follow a mask with an asterisk
1060 and repetition count For example "mask_mem:0*4,1*4". Not
1061 supported unless the entire node is allocated to the job.
1062 no[ne] don't bind tasks to memory (default)
1064 p[refer]
1066 Prefer use of first specified NUMA node, but permit
1067 use of other available NUMA nodes.
1068 q[uiet]
1070 quietly bind before task runs (default)
1071 rank bind by task rank (not recommended)
1073 sort sort free cache pages (run zonesort on Intel KNL nodes)
1075 v[erbose]
1077 verbosely report binding before task runs
1078 --mincpus=<n>
1081 Specify a minimum number of logical cpus/processors per node.
1082 -N, --nodes=<minnodes[-maxnodes]>
1085 Request that a minimum of minnodes nodes be allocated to this
1086 job. A maximum node count may also be specified with maxnodes.
1087 If only one number is specified, this is used as both the mini‐
1088 mum and maximum node count. The partition's node limits super‐
1089 sede those of the job. If a job's node limits are outside of
1090 the range permitted for its associated partition, the job will
1091 be left in a PENDING state. This permits possible execution at
1092 a later time, when the partition limit is changed. If a job
1093 node limit exceeds the number of nodes configured in the parti‐
1094 tion, the job will be rejected. Note that the environment vari‐
1095 able SLURM_JOB_NODES will be set to the count of nodes actually
1096 allocated to the job. See the ENVIRONMENT VARIABLES section for
1097 more information. If -N is not specified, the default behavior
1098 is to allocate enough nodes to satisfy the requirements of the
1099 -n and -c options. The job will be allocated as many nodes as
1100 possible within the range specified and without delaying the
1101 initiation of the job. The node count specification may include
1102 a numeric value followed by a suffix of "k" (multiplies numeric
1103 value by 1,024) or "m" (multiplies numeric value by 1,048,576).
1104 -n, --ntasks=<number>
1107 salloc does not launch tasks, it requests an allocation of
1108 resources and executed some command. This option advises the
1109 Slurm controller that job steps run within this allocation will
1110 launch a maximum of number tasks and sufficient resources are
1111 allocated to accomplish this. The default is one task per node,
1112 but note that the --cpus-per-task option will change this
1113 default.
1114 --network=<type>
1117 Specify information pertaining to the switch or network. The
1118 interpretation of type is system dependent. This option is sup‐
1119 ported when running Slurm on a Cray natively. It is used to
1120 request using Network Performance Counters. Only one value per
1121 request is valid. All options are case in-sensitive. In this
1122 configuration supported values include:
1123 system
1125 Use the system-wide network performance counters. Only
1126 nodes requested will be marked in use for the job alloca‐
1127 tion. If the job does not fill up the entire system the
1128 rest of the nodes are not able to be used by other jobs
1129 using NPC, if idle their state will appear as PerfCnts.
1130 These nodes are still available for other jobs not using
1131 NPC.
1132 blade Use the blade network performance counters. Only nodes
1134 requested will be marked in use for the job allocation.
1135 If the job does not fill up the entire blade(s) allocated
1136 to the job those blade(s) are not able to be used by other
1137 jobs using NPC, if idle their state will appear as PerfC‐
1138 nts. These nodes are still available for other jobs not
1139 using NPC.
1140 In all cases the job allocation request must specify the
1143 --exclusive option. Otherwise the request will be denied.
1144 Also with any of these options steps are not allowed to share
1146 blades, so resources would remain idle inside an allocation if
1147 the step running on a blade does not take up all the nodes on
1148 the blade.
1149 The network option is also supported on systems with IBM's Par‐
1151 allel Environment (PE). See IBM's LoadLeveler job command key‐
1152 word documentation about the keyword "network" for more informa‐
1153 tion. Multiple values may be specified in a comma separated
1154 list. All options are case in-sensitive. Supported values
1155 include:
1156 BULK_XFER[=<resources>]
1158 Enable bulk transfer of data using Remote Direct-
1159 Memory Access (RDMA). The optional resources speci‐
1160 fication is a numeric value which can have a suffix
1161 of "k", "K", "m", "M", "g" or "G" for kilobytes,
1162 megabytes or gigabytes. NOTE: The resources speci‐
1163 fication is not supported by the underlying IBM in‐
1164 frastructure as of Parallel Environment version 2.2
1165 and no value should be specified at this time.
1166 CAU=<count> Number of Collectve Acceleration Units (CAU)
1168 required. Applies only to IBM Power7-IH processors.
1169 Default value is zero. Independent CAU will be
1170 allocated for each programming interface (MPI, LAPI,
1171 etc.)
1172 DEVNAME=<name>
1174 Specify the device name to use for communications
1175 (e.g. "eth0" or "mlx4_0").
1176 DEVTYPE=<type>
1178 Specify the device type to use for communications.
1179 The supported values of type are: "IB" (InfiniBand),
1180 "HFI" (P7 Host Fabric Interface), "IPONLY" (IP-Only
1181 interfaces), "HPCE" (HPC Ethernet), and "KMUX" (Ker‐
1182 nel Emulation of HPCE). The devices allocated to a
1183 job must all be of the same type. The default value
1184 depends upon depends upon what hardware is available
1185 and in order of preferences is IPONLY (which is not
1186 considered in User Space mode), HFI, IB, HPCE, and
1187 KMUX.
1188 IMMED =<count>
1190 Number of immediate send slots per window required.
1191 Applies only to IBM Power7-IH processors. Default
1192 value is zero.
1193 INSTANCES =<count>
1195 Specify number of network connections for each task
1196 on each network connection. The default instance
1197 count is 1.
1198 IPV4 Use Internet Protocol (IP) version 4 communications
1200 (default).
1201 IPV6 Use Internet Protocol (IP) version 6 communications.
1203 LAPI Use the LAPI programming interface.
1205 MPI Use the MPI programming interface. MPI is the
1207 default interface.
1208 PAMI Use the PAMI programming interface.
1210 SHMEM Use the OpenSHMEM programming interface.
1212 SN_ALL Use all available switch networks (default).
1214 SN_SINGLE Use one available switch network.
1216 UPC Use the UPC programming interface.
1218 US Use User Space communications.
1220 Some examples of network specifications:
1223 Instances=2,US,MPI,SN_ALL
1225 Create two user space connections for MPI communica‐
1226 tions on every switch network for each task.
1227 US,MPI,Instances=3,Devtype=IB
1229 Create three user space connections for MPI communi‐
1230 cations on every InfiniBand network for each task.
1231 IPV4,LAPI,SN_Single
1233 Create a IP version 4 connection for LAPI communica‐
1234 tions on one switch network for each task.
1235 Instances=2,US,LAPI,MPI
1237 Create two user space connections each for LAPI and
1238 MPI communications on every switch network for each
1239 task. Note that SN_ALL is the default option so
1240 every switch network is used. Also note that
1241 Instances=2 specifies that two connections are
1242 established for each protocol (LAPI and MPI) and
1243 each task. If there are two networks and four tasks
1244 on the node then a total of 32 connections are
1245 established (2 instances x 2 protocols x 2 networks
1246 x 4 tasks).
1247 --nice[=adjustment]
1250 Run the job with an adjusted scheduling priority within Slurm.
1251 With no adjustment value the scheduling priority is decreased by
1252 100. A negative nice value increases the priority, otherwise
1253 decreases it. The adjustment range is +/- 2147483645. Only priv‐
1254 ileged users can specify a negative adjustment.
1255 --ntasks-per-core=<ntasks>
1258 Request the maximum ntasks be invoked on each core. Meant to be
1259 used with the --ntasks option. Related to --ntasks-per-node
1260 except at the core level instead of the node level. NOTE: This
1261 option is not supported unless SelectType=cons_res is configured
1262 (either directly or indirectly on Cray systems) along with the
1263 node's core count.
1264 --ntasks-per-node=<ntasks>
1267 Request that ntasks be invoked on each node. If used with the
1268 --ntasks option, the --ntasks option will take precedence and
1269 the --ntasks-per-node will be treated as a maximum count of
1270 tasks per node. Meant to be used with the --nodes option. This
1271 is related to --cpus-per-task=ncpus, but does not require knowl‐
1272 edge of the actual number of cpus on each node. In some cases,
1273 it is more convenient to be able to request that no more than a
1274 specific number of tasks be invoked on each node. Examples of
1275 this include submitting a hybrid MPI/OpenMP app where only one
1276 MPI "task/rank" should be assigned to each node while allowing
1277 the OpenMP portion to utilize all of the parallelism present in
1278 the node, or submitting a single setup/cleanup/monitoring job to
1279 each node of a pre-existing allocation as one step in a larger
1280 job script.
1281 --ntasks-per-socket=<ntasks>
1284 Request the maximum ntasks be invoked on each socket. Meant to
1285 be used with the --ntasks option. Related to --ntasks-per-node
1286 except at the socket level instead of the node level. NOTE:
1287 This option is not supported unless SelectType=cons_res is con‐
1288 figured (either directly or indirectly on Cray systems) along
1289 with the node's socket count.
1290 --no-bell
1293 Silence salloc's use of the terminal bell. Also see the option
1294 --bell.
1295 --no-shell
1298 immediately exit after allocating resources, without running a
1299 command. However, the Slurm job will still be created and will
1300 remain active and will own the allocated resources as long as it
1301 is active. You will have a Slurm job id with no associated pro‐
1302 cesses or tasks. You can submit srun commands against this
1303 resource allocation, if you specify the --jobid= option with the
1304 job id of this Slurm job. Or, this can be used to temporarily
1305 reserve a set of resources so that other jobs cannot use them
1306 for some period of time. (Note that the Slurm job is subject to
1307 the normal constraints on jobs, including time limits, so that
1308 eventually the job will terminate and the resources will be
1309 freed, or you can terminate the job manually using the scancel
1310 command.)
1311 -O, --overcommit
1314 Overcommit resources. When applied to job allocation, only one
1315 CPU is allocated to the job per node and options used to specify
1316 the number of tasks per node, socket, core, etc. are ignored.
1317 When applied to job step allocations (the srun command when exe‐
1318 cuted within an existing job allocation), this option can be
1319 used to launch more than one task per CPU. Normally, srun will
1320 not allocate more than one process per CPU. By specifying
1321 --overcommit you are explicitly allowing more than one process
1322 per CPU. However no more than MAX_TASKS_PER_NODE tasks are per‐
1323 mitted to execute per node. NOTE: MAX_TASKS_PER_NODE is defined
1324 in the file slurm.h and is not a variable, it is set at Slurm
1325 build time.
1326 -p, --partition=<partition_names>
1329 Request a specific partition for the resource allocation. If
1330 not specified, the default behavior is to allow the slurm con‐
1331 troller to select the default partition as designated by the
1332 system administrator. If the job can use more than one parti‐
1333 tion, specify their names in a comma separate list and the one
1334 offering earliest initiation will be used with no regard given
1335 to the partition name ordering (although higher priority parti‐
1336 tions will be considered first). When the job is initiated, the
1337 name of the partition used will be placed first in the job
1338 record partition string.
1339 --power=<flags>
1342 Comma separated list of power management plugin options. Cur‐
1343 rently available flags include: level (all nodes allocated to
1344 the job should have identical power caps, may be disabled by the
1345 Slurm configuration option PowerParameters=job_no_level).
1346 --priority=<value>
1349 Request a specific job priority. May be subject to configura‐
1350 tion specific constraints. value should either be a numeric
1351 value or "TOP" (for highest possible value). Only Slurm opera‐
1352 tors and administrators can set the priority of a job.
1353 --profile=<all|none|[energy[,|task[,|lustre[,|network]]]]>
1356 enables detailed data collection by the acct_gather_profile
1357 plugin. Detailed data are typically time-series that are stored
1358 in an HDF5 file for the job or an InfluxDB database depending on
1359 the configured plugin.
1360 All All data types are collected. (Cannot be combined with
1363 other values.)
1364 None No data types are collected. This is the default.
1367 (Cannot be combined with other values.)
1368 Energy Energy data is collected.
1371 Task Task (I/O, Memory, ...) data is collected.
1374 Lustre Lustre data is collected.
1377 Network Network (InfiniBand) data is collected.
1380 -q, --qos=<qos>
1383 Request a quality of service for the job. QOS values can be
1384 defined for each user/cluster/account association in the Slurm
1385 database. Users will be limited to their association's defined
1386 set of qos's when the Slurm configuration parameter, Account‐
1387 ingStorageEnforce, includes "qos" in it's definition.
1388 -Q, --quiet
1391 Suppress informational messages from salloc. Errors will still
1392 be displayed.
1393 --reboot
1396 Force the allocated nodes to reboot before starting the job.
1397 This is only supported with some system configurations and will
1398 otherwise be silently ignored.
1399 --reservation=<name>
1402 Allocate resources for the job from the named reservation.
1403 -s, --oversubscribe
1406 The job allocation can over-subscribe resources with other run‐
1407 ning jobs. The resources to be over-subscribed can be nodes,
1408 sockets, cores, and/or hyperthreads depending upon configura‐
1409 tion. The default over-subscribe behavior depends on system
1410 configuration and the partition's OverSubscribe option takes
1411 precedence over the job's option. This option may result in the
1412 allocation being granted sooner than if the --oversubscribe
1413 option was not set and allow higher system utilization, but
1414 application performance will likely suffer due to competition
1415 for resources. Also see the --exclusive option.
1416 -S, --core-spec=<num>
1419 Count of specialized cores per node reserved by the job for sys‐
1420 tem operations and not used by the application. The application
1421 will not use these cores, but will be charged for their alloca‐
1422 tion. Default value is dependent upon the node's configured
1423 CoreSpecCount value. If a value of zero is designated and the
1424 Slurm configuration option AllowSpecResourcesUsage is enabled,
1425 the job will be allowed to override CoreSpecCount and use the
1426 specialized resources on nodes it is allocated. This option can
1427 not be used with the --thread-spec option.
1428 --signal=<sig_num>[@<sig_time>]
1431 When a job is within sig_time seconds of its end time, send it
1432 the signal sig_num. Due to the resolution of event handling by
1433 Slurm, the signal may be sent up to 60 seconds earlier than
1434 specified. sig_num may either be a signal number or name (e.g.
1435 "10" or "USR1"). sig_time must have an integer value between 0
1436 and 65535. By default, no signal is sent before the job's end
1437 time. If a sig_num is specified without any sig_time, the
1438 default time will be 60 seconds. To have the signal sent at
1439 preemption time see the preempt_send_user_signal SlurmctldParam‐
1440 eter.
1441 --sockets-per-node=<sockets>
1444 Restrict node selection to nodes with at least the specified
1445 number of sockets. See additional information under -B option
1446 above when task/affinity plugin is enabled.
1447 --spread-job
1450 Spread the job allocation over as many nodes as possible and
1451 attempt to evenly distribute tasks across the allocated nodes.
1452 This option disables the topology/tree plugin.
1453 --switches=<count>[@<max-time>]
1456 When a tree topology is used, this defines the maximum count of
1457 switches desired for the job allocation and optionally the maxi‐
1458 mum time to wait for that number of switches. If Slurm finds an
1459 allocation containing more switches than the count specified,
1460 the job remains pending until it either finds an allocation with
1461 desired switch count or the time limit expires. It there is no
1462 switch count limit, there is no delay in starting the job.
1463 Acceptable time formats include "minutes", "minutes:seconds",
1464 "hours:minutes:seconds", "days-hours", "days-hours:minutes" and
1465 "days-hours:minutes:seconds". The job's maximum time delay may
1466 be limited by the system administrator using the SchedulerParam‐
1467 eters configuration parameter with the max_switch_wait parameter
1468 option. On a dragonfly network the only switch count supported
1469 is 1 since communication performance will be highest when a job
1470 is allocate resources on one leaf switch or more than 2 leaf
1471 switches. The default max-time is the max_switch_wait Sched‐
1472 ulerParameters.
1473 -t, --time=<time>
1476 Set a limit on the total run time of the job allocation. If the
1477 requested time limit exceeds the partition's time limit, the job
1478 will be left in a PENDING state (possibly indefinitely). The
1479 default time limit is the partition's default time limit. When
1480 the time limit is reached, each task in each job step is sent
1481 SIGTERM followed by SIGKILL. The interval between signals is
1482 specified by the Slurm configuration parameter KillWait. The
1483 OverTimeLimit configuration parameter may permit the job to run
1484 longer than scheduled. Time resolution is one minute and second
1485 values are rounded up to the next minute.
1486 A time limit of zero requests that no time limit be imposed.
1488 Acceptable time formats include "minutes", "minutes:seconds",
1489 "hours:minutes:seconds", "days-hours", "days-hours:minutes" and
1490 "days-hours:minutes:seconds".
1491 --thread-spec=<num>
1494 Count of specialized threads per node reserved by the job for
1495 system operations and not used by the application. The applica‐
1496 tion will not use these threads, but will be charged for their
1497 allocation. This option can not be used with the --core-spec
1498 option.
1499 --threads-per-core=<threads>
1502 Restrict node selection to nodes with at least the specified
1503 number of threads per core. NOTE: "Threads" refers to the num‐
1504 ber of processing units on each core rather than the number of
1505 application tasks to be launched per core. See additional
1506 information under -B option above when task/affinity plugin is
1507 enabled.
1508 --time-min=<time>
1511 Set a minimum time limit on the job allocation. If specified,
1512 the job may have it's --time limit lowered to a value no lower
1513 than --time-min if doing so permits the job to begin execution
1514 earlier than otherwise possible. The job's time limit will not
1515 be changed after the job is allocated resources. This is per‐
1516 formed by a backfill scheduling algorithm to allocate resources
1517 otherwise reserved for higher priority jobs. Acceptable time
1518 formats include "minutes", "minutes:seconds", "hours:min‐
1519 utes:seconds", "days-hours", "days-hours:minutes" and
1520 "days-hours:minutes:seconds".
1521 --tmp=<size[units]>
1524 Specify a minimum amount of temporary disk space per node.
1525 Default units are megabytes unless the SchedulerParameters con‐
1526 figuration parameter includes the "default_gbytes" option for
1527 gigabytes. Different units can be specified using the suffix
1528 [K|M|G|T].
1529 --usage
1532 Display brief help message and exit.
1533 --uid=<user>
1536 Attempt to submit and/or run a job as user instead of the invok‐
1537 ing user id. The invoking user's credentials will be used to
1538 check access permissions for the target partition. This option
1539 is only valid for user root. This option may be used by user
1540 root may use this option to run jobs as a normal user in a
1541 RootOnly partition for example. If run as root, salloc will drop
1542 its permissions to the uid specified after node allocation is
1543 successful. user may be the user name or numerical user ID.
1544 --use-min-nodes
1547 If a range of node counts is given, prefer the smaller count.
1548 -V, --version
1551 Display version information and exit.
1552 -v, --verbose
1555 Increase the verbosity of salloc's informational messages. Mul‐
1556 tiple -v's will further increase salloc's verbosity. By default
1557 only errors will be displayed.
1558 -w, --nodelist=<node name list>
1561 Request a specific list of hosts. The job will contain all of
1562 these hosts and possibly additional hosts as needed to satisfy
1563 resource requirements. The list may be specified as a
1564 comma-separated list of hosts, a range of hosts (host[1-5,7,...]
1565 for example), or a filename. The host list will be assumed to
1566 be a filename if it contains a "/" character. If you specify a
1567 minimum node or processor count larger than can be satisfied by
1568 the supplied host list, additional resources will be allocated
1569 on other nodes as needed. Duplicate node names in the list will
1570 be ignored. The order of the node names in the list is not
1571 important; the node names will be sorted by Slurm.
1572 --wait-all-nodes=<value>
1575 Controls when the execution of the command begins with respect
1576 to when nodes are ready for use (i.e. booted). By default, the
1577 salloc command will return as soon as the allocation is made.
1578 This default can be altered using the salloc_wait_nodes option
1579 to the SchedulerParameters parameter in the slurm.conf file.
1580 0 Begin execution as soon as allocation can be made. Do not
1582 wait for all nodes to be ready for use (i.e. booted).
1583 1 Do not begin execution until all nodes are ready for use.
1585 --wckey=<wckey>
1588 Specify wckey to be used with job. If TrackWCKey=no (default)
1589 in the slurm.conf this value is ignored.
1590 -x, --exclude=<node name list>
1593 Explicitly exclude certain nodes from the resources granted to
1594 the job.
1595 --x11[=<all|first|last>]
1598 Sets up X11 forwarding on all, first or last node(s) of the
1599 allocation. This option is only enabled if Slurm was compiled
1600 with X11 support and PrologFlags=x11 is defined in the
1601 slurm.conf. Default is all.
1602
1605 Upon startup, salloc will read and handle the options set in the fol‐
1606 lowing environment variables. Note: Command line options always over‐
1607 ride environment variables settings.
1608 SALLOC_ACCOUNT Same as -A, --account
1611 SALLOC_ACCTG_FREQ Same as --acctg-freq
1613 SALLOC_BELL Same as --bell
1615 SALLOC_BURST_BUFFER Same as --bb
1617 SALLOC_CLUSTERS or SLURM_CLUSTERS
1619 Same as --clusters
1620 SALLOC_CONSTRAINT Same as -C, --constraint
1622 SALLOC_CORE_SPEC Same as --core-spec
1624 SALLOC_CPUS_PER_GPU Same as --cpus-per-gpu
1626 SALLOC_DEBUG Same as -v, --verbose
1628 SALLOC_DELAY_BOOT Same as --delay-boot
1630 SALLOC_EXCLUSIVE Same as --exclusive
1632 SALLOC_GPUS Same as -G, --gpus
1634 SALLOC_GPU_BIND Same as --gpu-bind
1636 SALLOC_GPU_FREQ Same as --gpu-freq
1638 SALLOC_GPUS_PER_NODE Same as --gpus-per-node
1640 SALLOC_GPUS_PER_TASK Same as --gpus-per-task SALLOC_GRES Same as
1642 --gres
1643 SALLOC_GRES_FLAGS Same as --gres-flags
1645 SALLOC_HINT or SLURM_HINT
1647 Same as --hint
1648 SALLOC_IMMEDIATE Same as -I, --immediate
1650 SALLOC_KILL_CMD Same as -K, --kill-command
1652 SALLOC_MEM_BIND Same as --mem-bind
1654 SALLOC_MEM_PER_GPU Same as --mem-per-gpu
1656 SALLOC_NETWORK Same as --network
1658 SALLOC_NO_BELL Same as --no-bell
1660 SALLOC_NO_KILL Same as -k, --no-kill
1662 SALLOC_OVERCOMMIT Same as -O, --overcommit
1664 SALLOC_PARTITION Same as -p, --partition
1666 SALLOC_POWER Same as --power
1668 SALLOC_PROFILE Same as --profile
1670 SALLOC_QOS Same as --qos
1672 SALLOC_REQ_SWITCH When a tree topology is used, this defines the
1674 maximum count of switches desired for the job
1675 allocation and optionally the maximum time to
1676 wait for that number of switches. See --switches.
1677 SALLOC_RESERVATION Same as --reservation
1679 SALLOC_SIGNAL Same as --signal
1681 SALLOC_SPREAD_JOB Same as --spread-job
1683 SALLOC_THREAD_SPEC Same as --thread-spec
1685 SALLOC_TIMELIMIT Same as -t, --time
1687 SALLOC_USE_MIN_NODES Same as --use-min-nodes
1689 SALLOC_WAIT_ALL_NODES Same as --wait-all-nodes
1691 SALLOC_WCKEY Same as --wckey
1693 SALLOC_WAIT4SWITCH Max time waiting for requested switches. See
1695 --switches
1696 SLURM_CONF The location of the Slurm configuration file.
1698 SLURM_EXIT_ERROR Specifies the exit code generated when a Slurm
1700 error occurs (e.g. invalid options). This can be
1701 used by a script to distinguish application exit
1702 codes from various Slurm error conditions. Also
1703 see SLURM_EXIT_IMMEDIATE.
1704 SLURM_EXIT_IMMEDIATE Specifies the exit code generated when the
1706 --immediate option is used and resources are not
1707 currently available. This can be used by a
1708 script to distinguish application exit codes from
1709 various Slurm error conditions. Also see
1710 SLURM_EXIT_ERROR.
1711
1714 salloc will set the following environment variables in the environment
1715 of the executed program:
1716 SLURM_*_PACK_GROUP_#
1718 For a heterogeneous job allocation, the environment variables
1719 are set separately for each component.
1720 SLURM_CLUSTER_NAME
1722 Name of the cluster on which the job is executing.
1723 SLURM_CPUS_PER_GPU
1725 Number of CPUs requested per allocated GPU. Only set if the
1726 --cpus-per-gpu option is specified.
1727 SLURM_CPUS_PER_TASK
1729 Number of CPUs requested per task. Only set if the
1730 --cpus-per-task option is specified.
1731 SLURM_DISTRIBUTION
1733 Only set if the -m, --distribution option is specified.
1734 SLURM_GPUS
1736 Number of GPUs requested. Only set if the -G, --gpus option is
1737 specified.
1738 SLURM_GPU_BIND
1740 Requested binding of tasks to GPU. Only set if the --gpu-bind
1741 option is specified.
1742 SLURM_GPU_FREQ
1744 Requested GPU frequency. Only set if the --gpu-freq option is
1745 specified.
1746 SLURM_GPUS_PER_NODE
1748 Requested GPU count per allocated node. Only set if the
1749 --gpus-per-node option is specified.
1750 SLURM_GPUS_PER_SOCKET
1752 Requested GPU count per allocated socket. Only set if the
1753 --gpus-per-socket option is specified.
1754 SLURM_GPUS_PER_TASK
1756 Requested GPU count per allocated task. Only set if the
1757 --gpus-per-task option is specified.
1758 SLURM_JOB_ACCOUNT
1760 Account name associated of the job allocation.
1761 SLURM_JOB_ID (and SLURM_JOBID for backwards compatibility)
1763 The ID of the job allocation.
1764 SLURM_JOB_CPUS_PER_NODE
1766 Count of processors available to the job on this node. Note the
1767 select/linear plugin allocates entire nodes to jobs, so the
1768 value indicates the total count of CPUs on each node. The
1769 select/cons_res plugin allocates individual processors to jobs,
1770 so this number indicates the number of processors on each node
1771 allocated to the job allocation.
1772 SLURM_JOB_NODELIST (and SLURM_NODELIST for backwards compatibility)
1774 List of nodes allocated to the job.
1775 SLURM_JOB_NUM_NODES (and SLURM_NNODES for backwards compatibility)
1777 Total number of nodes in the job allocation.
1778 SLURM_JOB_PARTITION
1780 Name of the partition in which the job is running.
1781 SLURM_JOB_QOS
1783 Quality Of Service (QOS) of the job allocation.
1784 SLURM_JOB_RESERVATION
1786 Advanced reservation containing the job allocation, if any.
1787 SLURM_MEM_BIND
1789 Set to value of the --mem-bind option.
1790 SLURM_MEM_BIND_LIST
1792 Set to bit mask used for memory binding.
1793 SLURM_MEM_BIND_PREFER
1795 Set to "prefer" if the --mem-bind option includes the prefer
1796 option.
1797 SLURM_MEM_BIND_SORT
1799 Sort free cache pages (run zonesort on Intel KNL nodes)
1800 SLURM_MEM_BIND_TYPE
1802 Set to the memory binding type specified with the --mem-bind
1803 option. Possible values are "none", "rank", "map_map",
1804 "mask_mem" and "local".
1805 SLURM_MEM_BIND_VERBOSE
1807 Set to "verbose" if the --mem-bind option includes the verbose
1808 option. Set to "quiet" otherwise.
1809 SLURM_MEM_PER_CPU
1811 Same as --mem-per-cpu
1812 SLURM_MEM_PER_GPU
1814 Requested memory per allocated GPU. Only set if the
1815 --mem-per-gpu option is specified.
1816 SLURM_MEM_PER_NODE
1818 Same as --mem
1819 SLURM_PACK_SIZE
1821 Set to count of components in heterogeneous job.
1822 SLURM_SUBMIT_DIR
1824 The directory from which salloc was invoked or, if applicable,
1825 the directory specified by the -D, --chdir option.
1826 SLURM_SUBMIT_HOST
1828 The hostname of the computer from which salloc was invoked.
1829 SLURM_NODE_ALIASES
1831 Sets of node name, communication address and hostname for nodes
1832 allocated to the job from the cloud. Each element in the set if
1833 colon separated and each set is comma separated. For example:
1834 SLURM_NODE_ALIASES=ec0:1.2.3.4:foo,ec1:1.2.3.5:bar
1835 SLURM_NTASKS
1837 Same as -n, --ntasks
1838 SLURM_NTASKS_PER_CORE
1840 Set to value of the --ntasks-per-core option, if specified.
1841 SLURM_NTASKS_PER_NODE
1843 Set to value of the --ntasks-per-node option, if specified.
1844 SLURM_NTASKS_PER_SOCKET
1846 Set to value of the --ntasks-per-socket option, if specified.
1847 SLURM_PROFILE
1849 Same as --profile
1850 SLURM_TASKS_PER_NODE
1852 Number of tasks to be initiated on each node. Values are comma
1853 separated and in the same order as SLURM_JOB_NODELIST. If two
1854 or more consecutive nodes are to have the same task count, that
1855 count is followed by "(x#)" where "#" is the repetition count.
1856 For example, "SLURM_TASKS_PER_NODE=2(x3),1" indicates that the
1857 first three nodes will each execute three tasks and the fourth
1858 node will execute one task.
1859
1862 While salloc is waiting for a PENDING job allocation, most signals will
1863 cause salloc to revoke the allocation request and exit.
1864 However if the allocation has been granted and salloc has already
1866 started the specified command, then salloc will ignore most signals.
1867 salloc will not exit or release the allocation until the command exits.
1868 One notable exception is SIGHUP. A SIGHUP signal will cause salloc to
1869 release the allocation and exit without waiting for the command to fin‐
1870 ish. Another exception is SIGTERM, which will be forwarded to the
1871 spawned process.
1872
1875 To get an allocation, and open a new xterm in which srun commands may
1876 be typed interactively:
1877 $ salloc -N16 xterm
1879 salloc: Granted job allocation 65537
1880 (at this point the xterm appears, and salloc waits for xterm to
1881 exit)
1882 salloc: Relinquishing job allocation 65537
1883 To grab an allocation of nodes and launch a parallel application on one
1885 command line (See the salloc man page for more examples):
1886 salloc -N5 srun -n10 myprogram
1888 +To create a heterogeneous job with 3 components, each allocating a
1890 unique set of nodes:
1891 salloc -w node[2-3] : -w node4 : -w node[5-7] bash
1893 salloc: job 32294 queued and waiting for resources
1894 salloc: job 32294 has been allocated resources
1895 salloc: Granted job allocation 32294
1896
1899 Copyright (C) 2006-2007 The Regents of the University of California.
1900 Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER).
1901 Copyright (C) 2008-2010 Lawrence Livermore National Security.
1902 Copyright (C) 2010-2018 SchedMD LLC.
1903 This file is part of Slurm, a resource management program. For
1905 details, see <https://slurm.schedmd.com/>.
1906 Slurm is free software; you can redistribute it and/or modify it under
1908 the terms of the GNU General Public License as published by the Free
1909 Software Foundation; either version 2 of the License, or (at your
1910 option) any later version.
1911 Slurm is distributed in the hope that it will be useful, but WITHOUT
1913 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1914 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1915 for more details.
1916
1919 sinfo(1), sattach(1), sbatch(1), squeue(1), scancel(1), scontrol(1),
1920 slurm.conf(5), sched_setaffinity (2), numa (3)
1921October 2019 Slurm Commands salloc(1)