salloc(1)

NAME

salloc - Obtain a SLURM job allocation (a set of nodes), execute a command, and then release the allocation when the command is finished.

SYNOPSIS

salloc [options] <command> [command args]

DESCRIPTION

salloc is used to allocate a SLURM job allocation, which is a set of resources (nodes), possibly with some set of constraints (e.g. number of processors per node). When salloc successfully obtains the requested allocation, it then runs the command specified by the user. Finally, when the user specified command is complete, salloc relinquishes the job allocation. The command may be any program the user wishes. Some typical commands are xterm, a shell script containing slaunch commands, and slaunch (see the EXAMPLES section).

OPTIONS

-N, --nodes[=]<number|[min]-[max]>
    Specify the number of nodes to be used by this job step. This option accepts either a single number, or a range of possible node counts. If a single number is used, such as "-N 4", then the allocation is asking for four and ONLY four nodes. If a range is specified, such as "-N 2-6", the SLURM controller may grant salloc anywhere from 2 to 6 nodes. When using a range, either of the min or max options may be omitted. For instance, "-N 10-" means "no fewer than 10 nodes", and "-N -20" means "no more than 20 nodes". The default value of this option is one node, but other options implicitly increase the default node count.

-n, --tasks[=]<number>
    salloc does not launch tasks, it requests an allocation of resources and submits a batch script. However this --tasks option advizes the SLURM controller that job steps run within this allocation will launch a maximum of number tasks. This option, possibly with collaboration with the --cpus-per-task option, will directly impact the number of processors granted to the job allocation.

-d, --dependency[=]<jobid>
    Defer the start of this job until the specified jobid has completed. Many jobs can share the same dependency and these jobs may even belong to different users. The value may be changed after job submission using the scontrol command.

-s, --share
    The job allocation can share nodes with other running jobs. (The default shared/exclusive behaviour depends on system configuration.) This may result the allocation being granted sooner than if the --shared option was not set and allow higher system utilization, but application performance will likely suffer due to competition for resources within a node.

--exclusive
    The job allocation cannot share nodes with other running jobs. This is the oposite of --shared, whichever option is seen last on the command line will win. (The default shared/exclusive behaviour depends on system configuration.)

-t, --time[=]<minutes>
    Set a limit, in minites, on the total run time of the job allocation. If the requested time limit exceeds the partition's time limit, the job will be left in a PENDING state (possibly indefinitely). The default time limit is the partition's time limit. When the time limit is reached, the each task in each job step is sent SIGTERM followed by SIGKILL. The interval between signals is specified by the SLURM configuration parameter KillWait. A time limit of zero represents unlimited time.

-I,--immediate
    Grab the requested resources immediately, or abort if the resources are not currently available. The command parameter will not be run if the resources are not available.

-J, --job-name[=]<jobname>
    Specify a name for the job allocation. The specified name will appear along with the job id number when querying running jobs on the system. The default job name is the name of the "command" specified on the command line.

-W, --wait[=]<seconds>
    If the resources needed to satisy a job allocation are not immediately available, the job allocation is enqueued and is said to be PENDING. This option tells salloc how long (in seconds) to wait for the allocation to be granted before giving up. When the wait limit has been reached, salloc will exit without running the command parameter. By default, salloc will wait indefinitely. (The --immediate option makes --wait moot.)

-p, --partition[=]<partition name>
    Request a specific partition for the resource allocation. If not specified, the default behaviour is to allow the slurm controller to select the default partition as designated by the system administrator.

--contiguous
    Demand a contiguous range of nodes. The default is "yes". Specify --contiguous=no if a contiguous range of nodes is not required.

--mail-type=type
    Notify user by email when certain event types occur. Valid type values are BEGIN, END, FAIL, ALL (any state change). The user to be notified is indicated with --mail-user.

--mail-user=user
    User to receive email notification of state changes as defined by --mail-type. The default value is the username of the submitting user.

--uid[=]<user>
    Attempt to submit and/or run a job as user instead of the invoking user id. The invoking user's credentials will be used to check access permissions for the target partition. User root may use this option to run jobs as a normal user in a RootOnly partition for example. If run as root, salloc will drop its permissions to the uid specified after node allocation is successful. user may be the user name or numerical user ID.

--gid[=]<group>
    If salloc is run as root, and the --gid option is used, submit the job with group's group access permissions. group may be the group name or the numerical group ID.

-c, --cpus-per-task[=]<ncpus>
    Advise the SLURM controller that ensuing job steps will require ncpus number of processors per task. Without this option, the controller will just try to allocate one processor per task. For instance, consider an application that has 4 tasks, each requiring 3 processors. If our cluster is comprised of quad-processors nodes and we simply ask for 12 processors, the controller might give us only 3 nodes. However, by using the --cpus-per-task=3 options, the controller knows that each task requires 3 processors on the same node, and the controller will grant an allocation of 4 nodes, one for each of the 4 tasks.

-K, --kill-command[=signal]
    salloc always runs a user-specified command once the allocation is granted. salloc will wait indefinitely for that command to exit. If you specify the --kill-command option salloc will send a signal to your command any time that the SLURM controller tells salloc that its job allocation has been revoked. The job allocation can be revoked for a couple of reasons: someone used scancel to revoke the allocation, or the allocation reached its time limit. If you do not specify a signal name or number, the default signal is SIGTERM.

--bell
    Force salloc to ring the terminal bell when the job allocation is granted. By default, salloc only rings the bell if the allocation is pending for more than ten seconds.

--no-bell
    Silence salloc's use of the terminal bell.

--mincpus[=]<n>
    Specify minimum number of cpus per node.

--mem[=]<MB>
    Specify a minimum amount of real memory.

--tmp[=]<MB>
    Specify a minimum amount of temporary disk space.

-C, --constraint[=]<list>
    Specify a list of constraints. The constraints are features that have been assigned to the nodes by the slurm administrator. The list of constraints may include multiple features separated by ampersand (AND) and/or vertical bar (OR) operators. For example: --constraint="opteron&video" or --constraint="fast|faster". If no nodes have the requested features, then the job will be rejected by the slurm job manager.

-w, --nodelist[=]<node name list>
    Request a specific list of node names. The list may be specified as a comma-separated list of node names, or a range of node names (e.g. mynode[1-5,7,...]). Duplicate node names in the list will be ignored. The order of the node names in the list is not important; the node names will be sorted my SLURM.

-F, --nodefile[=]<node file>
    Much like --nodelist, but the list is contained in a file of name node file. The node names of the list may also span multiple lines in the file. Duplicate node names in the file will be ignored. The order of the node names in the list is not important; the node names will be sorted my SLURM.

-x, --exclude[=]<node name list>
    Explicitly exclude certain nodes from the resources granted to the job.

-D, --workdir[=]<directory>
    Set the working directory of the batch script to directory before it it executed.

-k, --no-kill
    Do not automatically terminate a job of one of the nodes it has been allocated fails. The user will assume the responsibilities for fault-tolerance should a node fail. When there is a node failure, any active job steps (usually MPI jobs) on that node will almost certainly suffer a fatal error, but with --no-kill, the job allocation will not be revoked so the user may launch new job steps on the remaining nodes in their allocation. By default SLURM terminates the entire job allocation if any node fails in its range of allocated nodes.

-U, --account[=]<account>
    Change resource use by this job to specified account. The account is an arbitrary string. The account name may be changed after job submission using the scontrol command.

--begin[=]<time>
    Submit the batch script to the SLURM controller immediately, like normal, but tell the controller to defer the allocation of the job until the specified time. Time may be of the form HH:MM:SS to run a job at a specific time of day (seconds are optional). (If that time is already past, the next day is assumed.) You may also specify midnight, noon, or teatime (4pm) and you can have a time-of-day suffixed with AM or PM for running in the morning or the evening. You can also say what day the job will be run, by giving a date in the form month-name day with an optional year, or giving a date of the form MMDDYY or MM/DD/YY or DD.MM.YY. You can also give times like now + count time-units, where the time-units can be minutes, hours, days, or weeks and you can tell SLURM to run the job today with the keyword today and to run the job tomorrow with the keyword tomorrow. The value may be changed after job submission using the scontrol command.

--comment
    An arbitrary comment.

--nice[=]<adjustment>
    Run the job with an adjusted scheduling priority. With no adjustment value the scheduling priority is decreased by 100. The adjustment range is from -10000 (highest priority) to 10000 (lowest priority). Only privileged users can specify a negative adjustment. NOTE: This option is presently ignored if SchedulerType=sched/maui.

--jobid
    Allocate resources as the specified job id. NOTE: Only valid for user root.

-q, --quiet
    Suppress informational messages from salloc. Errors will still be displayed.

-v, --verbose
    Increase the verbosity of salloc's informational messages. Multiple -v's will further increase salloc's verbosity.

-h, --help
    Display help information and exit.

-u, --usage
    Display brief usage message and exit.

-V, --version
    Display version information and exit.

The following options support Blue Gene systems, but may be applicable to other systems as well.

-g, --geometry[=]<XxYxZ>
    Specify the geometry requirements for the job. The three numbers represent the required geometry giving dimensions in the X, Y and Z directions. For example "--geometry=2x3x4", specifies a block of nodes having 2 x 3 x 4 = 24 nodes (actually base partions on Blue Gene).

--conn-type[=]<type>
    Require the partition connection type to be of a certain type. On Blue Gene the acceptable of type are MESH, TORUS and NAV. If NAV, or if not set, then SLURM will try to fit a TORUS else MESH. You should not normally set this option. SLURM will normally allocate a TORUS if possible for a given geometry.

-R, --no-rotate
    Disables rotation of the job's requested geometry in order to fit an appropriate partition. By default the specified geometry can rotate in three dimensions. Output version information and exit.

ENVIRONMENT VARIABLES

SALLOC_ACCOUNT
    Same as --account.

SALLOC_BELL
    Same as --bell.

SALLOC_NO_BELL
    Same as --no-bell.

SALLOC_CONN_TYPE
    Same as --conn-type.

SALLOC_DEBUG
    Same as -v or --verbose.

SALLOC_GEOMETRY
    Same as -g or --geometry.

SALLOC_IMMEDIATE
    Same as -I or --immediate.

SALLOC_JOBID
    Same as --jobid.

SALLOC_NO_ROTATE
    Same as -R or --no-rotate.

SALLOC_PARTITION
    Same as -p or --partition.

SALLOC_TIMELIMIT
    Same as -t or --time.

SALLOC_WAIT
    Same as -W or --wait.

SIGNALS

While salloc is waiting for a PENDING job allocation, most signals will cause salloc to revoke the allocation request and exit. However, if the allocation has been granted and salloc has already started the command speficied in its command line parameters salloc will ignore most signals. salloc will not exit or release the allocation until the command exits. The noteable exception is SIGHUP; a HUP signal will cause salloc to release the allocation and exit without waiting for the command to finish.

EXAMPLES

To get an allocation, and open a new xterm in which slaunch commands may be typed interactively:

    $ salloc -N16 xterm
    salloc: Granted job allocation 65537
    (at this point the xterm appears, and salloc waits for xterm to exit)
    salloc: Relinquishing job allocation 65537

To grab an allocation of nodes and launch a parallel application on one command line (See the salloc man page for more examples):

    salloc -N5 slaunch -n10 myprogram

COPYING
Copyright (C) 2006 The Regents of the University of California. Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER). UCRL-CODE-217948.

This file is part of SLURM, a resource management program. For details, see <http://www.llnl.gov/linux/slurm/>.

SLURM is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

SLURM is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

SEE ALSO

sinfo(1), slaunch(1), sattach(1), sbatch(1), squeue(1), scancel(1), scontrol(1), slurm.conf(5), sched_setaffinity(2), numa(3)