scancel(1)
π scancel(1) β Slurm Commands π
okay bestie, sit down, hydrate, and let me tell you about scancel, a.k.a. the Slurm command that says "girl, you're done" to jobs and job steps. this is part of the Slurm Commands family, and it's lowkey one of the most useful ones in the whole toolkit. π
πΈ NAME πΈ
scancel β used to signal jobs or job steps that are under the control of Slurm.
β¨ SYNOPSIS β¨
scancel [OPTIONS...] [job_id[_array_id][.step_id]]
[job_id[_array_id][.step_id]...]
π¦ DESCRIPTION π¦
so scancel is the one that signals or cancels jobs, job arrays, or job steps. you can signal literally an arbitrary number of them, either by using job specification filters or by handing it a space separated list of specific job and/or job step IDs. no cap. π
job arrays are where it gets spicy, so listen up:
- if you specify the job ID of a job array with an array ID value, and the job associated with that array ID value has been split from the array, then only that one job array element gets cancelled.
- if you specify the job ID of a job array without an array ID value, or the array ID value corresponds to a job that has not been split from the array, then all job array elements get cancelled.
now, heterogeneous jobs (het jobs, the main characters with many components):
- while a heterogeneous job is in a
PENDINGstate, you can only cancel the entire job β not its individual components. a request to cancel an individual component while it'sPENDINGwill return an error. like, that's not a vibe, that's just how it is. π - after the job has begun execution, an individual component can be cancelled β except for component zero. and if component zero is cancelled, the whole het job is cancelled. periodt.
step IDs are unique across the whole heterogeneous job. π
- cancelling a step through the job leader kills that step in every component that has it, and leaves the component allocations running.
- cancelling a step through an individual component signals only that component's step. it is not an error for a component not to have that step; only a step ID that no component has gets reported as an invalid job ID.
- signals other than the default
SIGKILLare sent only to the step of the component whose job ID was given.
(and yes bestie, the original page says the leader thing twice in slightly different words β component zero is the heterogeneous job leader, and cancelling a step through it kills that step in every component that has it while leaving the component allocations running. also, it's still not an error if some components don't have that step; only a step ID that no component has is reported as an invalid job ID. and cancelling a step through an individual component signals only that component's step β if that component doesn't have the step, the request is reported as an invalid job ID. two ways of saying one truth, we love a consistent queen π)
one more thing, and it's important:
a job or job step can only be signaled by the owner of that job or by user root. if an unauthorized user tries it, an error message gets printed and the job will not be signaled. bye. π
π OPTIONS π
-A,--account=accountβ restrict thescanceloperation to jobs under this charge account.--admin-comment=commentβ set theAdminCommenton the job while canceling jobs. user must have Administrator privileges on the system.-b,--batchβ by default, signals other thanSIGKILLare not sent to the batch step (the shell script). with this optionscancelsignals only the batch step, but not any other steps. this is useful when the shell script has to trap the signal and take some application defined action. most shells cannot handle signals while a command is running (i.e. is a child process of the batch step), so the shell needs to wait until the command ends to then handle the signal. children of the batch step are not signaled with this option β if that's what you want, use-f,--fullinstead. NOTE: if used with-f,--full, this option is ignored. NOTE: this option is not applicable if step_id is specified. NOTE: the shell itself may exit upon receipt of many signals. you may avoid this by explicitly trap signals within the shell script (e.g."trap <arg> <signals>"). see the shell documentation for details.-M,--clusters=<string>β cluster to issue commands to. implies--ctld. note that theslurmdbdmust be up for this option to work properly, unless running in a federation withFederationParameters=fed_displayconfigured.--ctldβ if this option is not used with--interactive,--sibling, federated job ids, or specific step ids, then this issues a single request to theslurmctldto signal all jobs matching the specified filters. this greatly improves the performance ofslurmctldandscancel. otherwise, this option causesscancelto send each job signal request to theslurmctlddaemon rather than directly to theslurmddaemons, which increases overhead, but offers better fault tolerance.--ctldis the default behavior on when the--clustersoption is used.-c,--cronβ confirm request to cancel a job submitted byscrontab. this option only has effect with the"explicit_scancel"option is set inScronParameters.-f,--fullβ by default, signals other thanSIGKILLare not sent to the batch step (the shell script). with this optionscancelalso signals the batch script and its children processes. most shells cannot handle signals while a command is running (i.e. is a child process of the batch step), so the shell needs to wait until the command ends to then handle the signal. unlike-b,--batch, children of the batch step are also signaled with this option. NOTE:srunsteps are also children of the batch step, so steps are also signaled with this option.--helpβ print a help message describing allscanceloptions. π«Ά-H,--hurryβ do not stage out any burst buffer data.-i,--interactiveβ interactive mode. confirm each job_id.step_id before performing the cancel operation.-n,--jobname=job_name,--name=job_nameβ restrict thescanceloperation to jobs with this job name.--meβ restrict thescanceloperation to jobs owned by the current user. (it's giving main character energy, honestly β¨)-w,--nodelist=host1,host2,...β cancel any jobs using any of the given hosts. the list may be specified as a comma-separated list of hosts, a range of hosts (host[1-5,7,...]for example), or a filename. the host list will be assumed to be a filename only if it contains a"/"character.-p,--partition=partition_nameβ restrict thescanceloperation to jobs in this partition.-q,--qos=qosβ restrict thescanceloperation to jobs with this quality of service.-Q,--quietβ do not report an error if the specified job is already completed. this option is incompatible with the--verboseoption.-R,--reservation=reservation_nameβ restrict thescanceloperation to jobs with this reservation name.--sibling=cluster_nameβ remove an active sibling job from a federated job.-s,--signal=signal_nameβ the name or number of the signal to send. if this option is not used the specified job or step will be terminated.-t,--state=job_state_nameβ restrict thescanceloperation to jobs in this state. job_state_name may have a value of either"PENDING","RUNNING"or"SUSPENDED".--usageβ print a brief help message listing thescanceloptions.-u,--user=user_nameβ restrict thescanceloperation to jobs owned by the given user.-v,--verboseβ print additional logging. multiple v's increase logging detail. this option is incompatible with the--quietoption.-V,--versionβ print the version number of thescancelcommand.--wckey=wckeyβ restrict thescanceloperation to jobs using this workload characterization key.
π ARGUMENTS π
πΈ job_id
the Slurm job ID to be signaled. a SLUID may also be used in place of a numeric job ID. iconic, honestly.
πΈ step_id
the step ID of the job step to be signaled. if not specified, the operation is performed at the level of a job.
- if neither
--batchnor--signalare used, the entire job will be terminated. - when
--batchis used, the batch shell processes will be signaled. the child processes of the shell will not be signaled by Slurm, but the shell may forward the signal. - when
--batchis not used but--signalis used, then all job steps will be signaled, but the batch script itself will not be signaled.
π₯ PERFORMANCE π₯
okay this part matters, bestie, don't skip it. π«Ά
when executing scancel without the --ctld option; or with the --ctld option and --interactive, --sibling, or specific step ids β a remote procedure call is sent to slurmctld to get all the jobs. scancel then sends a signal job remote procedure call for each job that matches the requested filters. that's a lot of little calls, one per job.
when executing scancel with the --ctld option and without --interactive, --sibling, or specific step ids β a single remote procedure call is sent to slurmctld to signal all jobs matching the requested filters. it is therefore recommended to use the --ctld option in order to reduce the number of remote procedure calls sent to the slurmctld. periodt. π
if enough calls fromscancelor other Slurm client commands that send remote procedure calls to theslurmctlddaemon come in at once, it can result in a degradation of performance of theslurmctlddaemon, possibly resulting in a denial of service. π
do not run scancel or other Slurm client commands that send remote procedure calls to slurmctld from loops in shell scripts or other programs. ensure that programs limit calls to scancel to the minimum necessary for the information you are trying to gather. we do not spam the daemon in this house. π
ββοΈ
π ENVIRONMENT VARIABLES π
some scancel options may be set via environment variables. these environment variables, along with their corresponding options, are listed below. (Note: command line options will always override these settings.)
SCANCEL_ACCOUNTβ-A,--account=accountSCANCEL_BATCHβ-b,--batchSCANCEL_CTLDβ--ctldSCANCEL_CRONβ-c,--cronSCANCEL_FULLβ-f,--fullSCANCEL_HURRYβ-H,--hurrySCANCEL_INTERACTIVEβ-i,--interactiveSCANCEL_NAMEβ-n,--name=job_nameSCANCEL_PARTITIONβ-p,--partition=partition_nameSCANCEL_QOSβ-q,--qos=qosSCANCEL_STATEβ-t,--state=job_state_nameSCANCEL_USERβ-u,--user=user_nameSCANCEL_VERBOSEβ-v,--verboseSCANCEL_WCKEYβ--wckey=wckeySLURM_CONFβ the location of the Slurm configuration file.SLURM_CLUSTERSβ-M,--clustersSLURM_DEBUG_FLAGSβ specify debug flags forscancelto use. seeDebugFlagsin theslurm.conf(5)man page for a full list of flags. the environment variable takes precedence over the setting in theslurm.conf.
π NOTES π
okay bestie, listen up, there's some lore here that you need:
- if you hand over multiple filters at once (like
--partitionand--nametogether, iykyk), then only the jobs that satisfy all of those filtering options get signaled. it's giving "and", not "or", periodt. π - cancelling a job step will not terminate the job itself. like, the job is still there, bestie. if you want that resource allocation back, you have to cancel the job. no cap. π
- to cancel a job, just invoke
scancelwithout the--signaloption. here's the little choreography it does, and honestly it's kind of iconic:- sends a
SIGCONTto all steps first, to eventually wake them up π - then a
SIGTERM - then it waits the
KillWaitduration defined in theslurm.conffile β³ - and finally, if they still haven't terminated, it sends a
SIGKILLπ
- sends a
so yeah, it's literally giving your running job/step(s) time to clean up. so thoughtful of it fr fr.
- oh and heads up: if you send a signal value of
"KILL"to an entire job, it will cancel the active job steps but not cancel the job itself. the way that's a whole trap π
π AUTHORIZATION π
when you're using SlurmDBD, here's who gets to boss other people's jobs around:
- users who have an
AdminLeveldefined (Operator or Admin) β¨ - and users who are account coordinators π«Ά
those people are given the authority to invoke scancel on other users' jobs. everyone else? stay in your lane bestie π
πΈ EXAMPLES πΈ
okay these are the main character examples, run them exactly like this:
Send SIGTERM to steps 1 and 3 of job 1234:
$ scancel --signal=TERM 1234.1 1234.3
Cancel job 1234 along with all of its steps:
$ scancel 1234
Send SIGKILL to all steps of job 1235, but do not cancel the job itself:
$ scancel --signal=KILL 1235
Send SIGUSR1 to the batch shell processes of job 1236:
$ scancel --signal=USR1 --batch 1236
Cancel all pending jobs belonging to user "bob" in partition "debug":
$ scancel --state=PENDING --user=bob --partition=debug
Cancel only array ID 4 of job array 1237
$ scancel 1237_4
like, look at that. --state=PENDING --user=bob --partition=debug with zero positional args? that's the vibe check passing. π₯
π COPYING π
okay now the legal bit, and yes we read it, we don't skip it:
Copyright (C) 2002-2007 The Regents of the University of California. Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER). Copyright (C) 2008-2011 Lawrence Livermore National Security. Copyright (C) 2010-2022 SchedMD LLC.
This file is part of Slurm, a resource management program. For details, see <https://slurm.schedmd.com/>.
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.
bestie the all-caps in that warranty section is not me being dramatic, that's literally how it's written. respect the caps. π€
π¦ SEE ALSO π¦
go read these next, they're the friends of this page:
slurm_kill_job(3)slurm_kill_job_step(3)
and that's a wrap on scancel(1) from the Slurm Commands collection, page version Slurm 26.05 π go forth and cancel responsibly, bestie. slay. πβ¨π
π¦ where this page comes from
- arch rolling: slurm-llnl 26.05.5.1-1 Β· GPL-2.0-or-later
- epel 10: slurm 26.05.5-1.el10_3 Β· GPL-2.0-or-later AND BSD-2-Clause AND BSD-1-Clause
- nixpkgs unstable: slurm 26-05-5-1
- ubuntu stonking: slurm-client 26.05.4-1ubuntu1 Β· GPL-2.0-or-later WITH OpenSSL exception
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms