neulab/tldr huggingface dataset:
When rename/copy is involved, file1 and file2 show the name of the source file of the rename/copy and the name of the file that rename/copy produces, respectively.
2. It is followed by one or more extended header lines:
old mode <mode> new mode <mode> deleted file mode <mode> new file mode <mode> copy from <path> copy to <path> rename from <path> rename to <path> similarity index <number> dissimilarity index <number> index <hash>..<hash> <mode>
File modes are printed as 6-digit octal numbers including the file type and file permission bits.
Path names in extended headers do not include the a/ and b/ prefixes.
The similarity index is the percentage of unchanged lines, and the dissimilarity index is the percentage of changed lines. It is a rounded down integer, followed by a percent sign. The similarity index value of 100% is thus reserved for two equal files, while 100% dissimilarity means that no line from the old file made it into the new one.
The index line includes the blob object names before and after the change. The <mode> is included if the file mode does not change; otherwise, separate lines indicate the old and the new mode.
3. Pathnames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git-config(1)).
4. All the file1 files in the output refer to files before the commit, and all the file2 files refer to files after the commit. It is incorrect to apply each change to each file sequentially. For example, this patch will swap a and b:
diff --git a/a b/b rename from a rename to b diff --git a/b b/a rename from b rename to a
5. Hunk headers mention the name of the function to which the hunk applies. See "Defining a custom hunk-header" in gitattributes(5) for details of how to tailor to this to specific languages.
Any diff-generating command can take the -c or --cc option to produce a combined diff when showing a merge. This is the default format when showing merges with git-diff(1) or git-show(1). Note also that you can give suitable --diff-merges option to any of these commands to force generation of diffs in specific format.
A "combined diff" format looks like this:
diff --combined describe.c index fabadb8,cc95eb0..4866510 --- a/describe.c +++ b/describe.c @@@ -98,20 -98,12 +98,20 @@@ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; }
- static void describe(char *arg) -static void describe(struct commit *cmit, int last_one) ++static void describe(char *arg, int last_one) { +      unsigned char sha1[20]; +      struct commit *cmit; struct commit_list *list; static int initialized = 0; struct commit_name *n;
+      if (get_sha1(arg, sha1) < 0) +              usage(describe_usage); +      cmit = lookup_commit_reference(sha1); +      if (!cmit) +              usage(describe_usage); + if (!initialized) { initialized = 1; for_each_ref(get_name);
1. It is preceded with a "git diff" header, that looks like this (when the -c option is used):
diff --combined file
or like this (when the --cc option is used):
diff --cc file
2. It is followed by one or more extended header lines (this example shows a merge with two parents):
index <hash>,<hash>..<hash> mode <mode>,<mode>..<mode> new file mode <mode> deleted file mode <mode>,<mode>
The mode <mode>,<mode>..<mode> line appears only if at least one of the <mode> is different from the rest. Extended headers with information about detected contents movement (renames and copying detection) are designed to work with diff of two <tree-ish> and are not used by combined diff format.
3. It is followed by two-line from-file/to-file header
--- a/file +++ b/file
Similar to two-line header for traditional unified diff format, /dev/null is used to signal created or deleted files.
However, if the --combined-all-paths option is provided, instead of a two-line from-file/to-file you get a N+1 line from-file/to-file header, where N is the number of parents in the merge commit
--- a/file --- a/file --- a/file +++ b/file
This extended format can be useful if rename or copy detection is active, to allow you to see the original name of the file in different parents.
4. Chunk header format is modified to prevent people from accidentally feeding it to patch -p1. Combined diff format was created for review of merge commit changes, and was not meant to be applied. The change is similar to the change in the extended index header:
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
There are (number of parents + 1) @ characters in the chunk header for combined diff format.
Unlike the traditional unified diff format, which shows two files A and B with a single column that has - (minus — appears in A but removed in B), + (plus — missing in A but added to B), or " " (space — unchanged) prefix, this format compares two or more files file1, file2,... with one file X, and shows how X differs from each of fileN. One column for each of fileN is prepended to the output line to note how X’s line is different from it.
A - character in the column N means that the line appears in fileN but it does not appear in the result. A + character in the column N means that the line appears in the result, and fileN does not have that line (in other words, the line was added, from the point of view of that parent).
In the above example output, the function signature was changed from both files (hence two - removals from both file1 and file2, plus ++ to mean one line that was added does not appear in either file1 or file2). Also eight other lines are the same from file1 but do not appear in file2 (hence prefixed with +).
When shown by git diff-tree -c, it compares the parents of a merge commit with the merge result (i.e. file1..fileN are the parents). When shown by git diff-files -c, it compares the two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version").
The --summary option describes newly added, deleted, renamed and copied files. The --stat option adds diffstat(1) graph to the output. These options can be combined with other options, such as -p, and are meant for human consumption.
When showing a change that involves a rename or a copy, --stat output formats the pathnames compactly by combining common prefix and suffix of the pathnames. For example, a change that moves arch/i386/Makefile to arch/x86/Makefile while modifying 4 lines will be shown like this:
arch/{i386 => x86}/Makefile    |   4 +--
The --numstat option gives the diffstat(1) information but is designed for easier machine consumption. An entry in --numstat output looks like this:
1       2       README 3       1       arch/{i386 => x86}/Makefile
That is, from left to right:
1. the number of added lines;
2. a tab;
3. the number of deleted lines;
4. a tab;
5. pathname (possibly with rename/copy information);
6. a newline.
When -z output option is in effect, the output is formatted this way:
1       2       README NUL 3       1       NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
5. a NUL (only exists if renamed/copied);
6. pathname in preimage;
7. a NUL (only exists if renamed/copied);
8. pathname in postimage (only exists if renamed/copied);
9. a NUL.
The extra NUL before the preimage path in renamed case is to allow scripts that read the output to tell if the current record being read is a single-path record or a rename/copy record without reading ahead. After reading added and deleted lines, reading up to NUL would yield the pathname, but if that is NUL, the record will show two paths.
Various ways to check your working tree
$ git diff            (1) $ git diff --cached   (2) $ git diff HEAD       (3)
1. Changes in the working tree not yet staged for the next commit. 2. Changes between the index and your last commit; what you would be committing if you run git commit without -a option. 3. Changes in the working tree since your last commit; what you would be committing if you run git commit -a
Comparing with arbitrary commits
$ git diff test            (1) $ git diff HEAD -- ./test  (2) $ git diff HEAD^ HEAD      (3)
1. Instead of using the tip of the current branch, compare with the tip of "test" branch. 2. Instead of comparing with the tip of "test" branch, compare with the tip of the current branch, but limit the comparison to the file "test". 3. Compare the version before the last commit and the last commit.
Comparing branches
$ git diff topic master    (1) $ git diff topic..master   (2) $ git diff topic...master  (3)
1. Changes between the tips of the topic and the master branches. 2. Same as above. 3. Changes that occurred on the master branch since when the topic branch was started off it.
Limiting the diff output
$ git diff --diff-filter=MRC            (1) $ git diff --name-status                (2) $ git diff arch/i386 include/asm-i386   (3)
1. Show only modification, rename, and copy, but not addition or deletion. 2. Show only names and the nature of change, but not actual diff output. 3. Limit diff output to named subtrees.
Munging the diff output
$ git diff --find-copies-harder -B -C  (1) $ git diff -R                          (2)
1. Spend extra cycles to find renames, copies and complete rewrites (very expensive). 2. Output diff in reverse.
diff(1), git-difftool(1), git-log(1), gitdiffcore(7), git-format- patch(1), git-apply(1), git-show(1)
kubectl run - Run a particular image on the cluster
kubectl run [OPTIONS]
Create and run a particular image in a pod.
--allow-missing-template-keys=true      If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.
--annotations=[]      Annotations to apply to the pod.
--attach=false      If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl attach ...' were called.  Default false, unless '-i/--stdin' is set, in which case the default is true. With '--restart=Never' the exit code of the container process is returned.
--cascade="background"      Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents (e.g. Pods created by a ReplicationController). Defaults to background.
--command=false      If true and extra arguments are present, use them as the 'command' field in the container, rather than the 'args' field which is the default.
--dry-run="none"      Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource.
--env=[]      Environment variables to set in the container.
--expose=false      If true, service is created for the container(s) which are run
--field-manager="kubectl-run"      Name of the manager used to track field ownership.
-f, --filename=[]      to use to replace the resource.
--force=false      If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation.
--grace-period=-1      Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true (force deletion).
--hostport=-1      The host port mapping for the container port. To demonstrate a single-machine container.
--image=""      The image for the container to run.
--image-pull-policy=""      The image pull policy for the container. If left empty, this value will not be specified by the client and defaulted by the server
-k, --kustomize=""      Process a kustomization directory. This flag can't be used together with -f or -R.
-l, --labels=""      Comma separated labels to apply to the pod(s). Will override previous values.
--leave-stdin-open=false      If the pod is started in interactive mode or with stdin, leave stdin open after the first attach completes. By default, stdin will be closed after the first attach completes.
--limits=""      The resource requirement limits for this container.  For example, 'cpu=200m,memory=512Mi'.  Note that server side components may assign limits depending on the server configuration, such as limit ranges.
-o, --output=""      Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.
--overrides=""      An inline JSON override for the generated object. If this is non-empty, it is used to override the generated object. Requires that the object supply a valid apiVersion field.
--pod-running-timeout=1m0s      The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running
--port=""      The port that this container exposes.
--privileged=false      If true, run the container in privileged mode.
-q, --quiet=false      If true, suppress prompt messages.
--record=false      Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists.
-R, --recursive=false      Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory.
--requests=""      The resource requirement requests for this container. For example, 'cpu=100m,memory=256Mi'.  Note that server side components may assign requests depending on the server configuration, such as limit ranges.
--restart="Always"      The restart policy for this Pod.  Legal values [Always, OnFailure, Never].
--rm=false      If true, delete resources created in this command for attached containers.
--save-config=false      If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
--serviceaccount=""      Service account to set in the pod spec.
--show-managed-fields=false      If true, keep the managedFields when printing objects in JSON or YAML format.
-i, --stdin=false      Keep stdin open on the container(s) in the pod, even if nothing is attached.
--template=""      Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
--timeout=0s      The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object
-t, --tty=false      Allocated a TTY for each container in the pod.
--wait=false      If true, wait for resources to be gone before returning. This waits for finalizers.
# Start a nginx pod kubectl run nginx --image=nginx
# Start a hazelcast pod and let the container expose port 5701 kubectl run hazelcast --image=hazelcast/hazelcast --port=5701
# Start a hazelcast pod and set environment variables "DNS_DOMAIN=cluster" and "POD_NAMESPACE=default" in the container kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"
# Start a hazelcast pod and set labels "app=hazelcast" and "env=prod" in the container kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"
# Dry run; print the corresponding API objects without creating them kubectl run nginx --image=nginx --dry-run=client
# Start a nginx pod, but overload the spec with a partial set of values parsed from JSON kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'
# Start a busybox pod and keep it in the foreground, don't restart it if it exits kubectl run -i -t busybox --image=busybox --restart=Never
# Start the nginx pod using the default command, but use custom arguments (arg1 .. argN) for that command kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>
# Start the nginx pod using a different command and custom arguments kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>
DIRSEARCH(1)                       SFS 0.8pre                       DIRSEARCH(1)
dirsearch - search for file in directories
dirsearch [-c | -l | -p | -q] dir1 [dir2 ...] name
dirsearch looks for a file name in one or more directories.  Starting with dir1, the command searches each directory specified for a file called name.  If such a file is found, dirsearch exits with code 0 and, depending on its options, may print the file's pathname, contents, or expanded symbolic link contents.  If none of the directories specified contain a file name, dirsearch exits with code 1 and prints no output.
The following mutually exclusive options affect the behavior of dirsearch.  If more than one option is specified, only the last will have an effect.
-c  This option prints the contents of the file when it is found, instead of its pathname.
-l  This option looks for symbolic links.  The file name will be ignored if it is not a symbolic link.  Furthermore, in its output dirsearch will expand the symbolic link.
-p  This option says to print the pathname, which is the default anyway. Thus, the only effect of -p is to undo any previous -c, -l, or -q option.
-q  This option suppresses any output dirsearch would print.  The exit code still indicates whether or not the file exists.
dirsearch is particularly useful for SFS certification and revocation programs.  As an example, suppose you have a directory of symbolic links in your home directory called .sfs/bookmarks.  The directory might contain the following links: sfs.fs.net -> /sfs/@sfs.fs.net,uzwadtctbjb3dg596waiyru8cx5kb4an sfs.nyu.edu -> /sfs/@sfs.nyu.edu,hcbafipmin3eqmsgak2m6heequppitiz
If you execute the command: sfskey certprog dirsearch -l ~/.sfs/bookmarks
Then the next time you access /sfs/sfs.fs.net, that pathname will automatically become a symbolic link to your bookmark.  Moreover, the same will happen on remote machines to which you log in with the rex command.
newaid(1), rex(1), sfsagent(1), sfskey(1), ssu(1), sfs_config(5), sfs_hosts(5), sfs_srp_params(5), sfs_users(5), sfsauthd_config(5), sfscd_config(5), sfsrosd_config(5), sfsrwsd_config(5), sfssd_config(5), sfs_environ(7), funmount(8), nfsmounter(8), sfsauthd(8), sfscd(8), sfsrosd(8), sfsrwcd(8), sfsrwsd(8), sfssd(8), vidb(8)
The full documentation for SFS is maintained as a Texinfo manual.  If the info and SFS programs are properly installed at your site, the command info SFS should give you access to the complete manual.
For updates, documentation, and software distribution, please see the SFS website at http://www.fs.net/.
sfsdev@redlab.lcs.mit.edu
XTRLOCK(1)                   General Commands Manual                  XTRLOCK(1)
xtrlock - Lock X display until password supplied, leaving windows visible
xtrlock [-b] [-f]
xtrlock locks the X server till the user enters their password at the keyboard.
While xtrlock is running, the mouse and keyboard are grabbed and the mouse cursor becomes a padlock.  Output displayed by X programs, and windows put up by new X clients, continue to be visible, and any new output is displayed normally.
The mouse and keyboard are returned when the user types their password, followed by Enter or Newline.  If an incorrect password is entered the bell is sounded.  Pressing Backspace or Delete erases one character of a password partially typed; pressing Escape or Clear clears anything that has been entered.
If too many attempts are made in too short a time further keystrokes generate bells and are otherwise ignored until a timeout has expired.
The X server screen saver continues to operate normally; if it comes into operation the display may be restored by the usual means of touching a key (Shift, for example) or the mouse.
-b     blank the screen as well as displaying the padlock
-f     fork after locking is complete, and return success from the parent process
X RESOURCES, CONFIGURATION None.
Additional input devices other than the keyboard and mouse are not disabled.
The timeouts, bitmaps and mouse cursor colour cannot be modifed.
X(1), Xlib Documentation.
Ian Jackson <ian@chiark.greenend.org.uk>
Copyright (C) 1993, 1994 by Ian Jackson.
Permission to use, copy, modify and distribute this software and its documentation is granted under the terms of the GNU General Public Licence, version 2 or later, as published by the Free Software Foundation.
AUDITD(8)                System Administration Utilities               AUDITD(8)
auditd - The Linux Audit daemon
auditd [-f] [-l] [-n] [-s disable|enable|nochange] [-c <config_dir>]
auditd is the userspace component to the Linux Auditing System. It's responsible for writing audit records to the disk. Viewing the logs is done with the ausearch or aureport utilities. Configuring the audit system or loading rules is done with the auditctl utility. During startup, the rules in /etc/audit/audit.rules are read by auditctl and loaded into the kernel. Alternately, there is also an augenrules program that reads rules located in /etc/audit/rules.d/ and compiles them into an audit.rules file. The audit daemon itself has some configuration options that the admin may wish to customize. They are found in the auditd.conf file.
-f     leave the audit daemon in the foreground for debugging. Messages also go to stderr rather than the audit log.
-l     allow the audit daemon to follow symlinks for config files.
-n     no fork. This is useful for running off of inittab or systemd.
-s=ENABLE_STATE specify when starting if auditd should change the current value for the kernel enabled flag. Valid values for ENABLE_STATE are "disable", "enable" or "nochange". The default is to enable (and disable when auditd terminates). The value of the enabled flag may be changed during the lifetime of auditd using 'auditctl -e'.
-c     Specify alternate config file directory. Note that this same directory will be passed to the dispatcher. (default: /etc/audit/)
SIGHUP causes auditd to reconfigure. This means that auditd re-reads the configuration file. If there are no syntax errors, it will proceed to implement the requested changes. If the reconfigure is successful, a DAEMON_CONFIG event is recorded in the logs. If not successful, error handling is controlled by space_left_action, admin_space_left_action, disk_full_action, and disk_error_action parameters in auditd.conf.
SIGTERM caused auditd to discontinue processing audit events, write a shutdown audit event, and exit.
SIGUSR1 causes auditd to immediately rotate the logs. It will consult the max_log_file_action to see if it should keep the logs or not.
SIGUSR2 causes auditd to attempt to resume logging and passing events to plugins. This is usually needed after logging has been suspended or the internal queue is overflowed. Either of these conditions depends on the applicable configuration settings.
SIGCONT causes auditd to dump a report of internal state to /var/run/auditd.state.
1      Cannot adjust priority, daemonize, open audit netlink, write the pid file, start up plugins, resolve the machine name, set audit pid, or other initialization tasks.
2      Invalid or excessive command line arguments
4      The audit daemon doesn't have sufficient privilege
6      There is an error in the configuration file
/etc/audit/auditd.conf - configuration file for audit daemon
/etc/audit/audit.rules - audit rules to be loaded at startup
/etc/audit/rules.d/ - directory holding individual sets of rules to be compiled into one file by augenrules.
/etc/audit/plugins.d/ - directory holding individual plugin configuration files.
/var/run/auditd.state - report about internal state.
A boot param of audit=1 should be added to ensure that all processes that run before the audit daemon starts is marked as auditable by the kernel. Not doing that will make a few processes impossible to properly audit.
The audit daemon can receive audit events from other audit daemons via the audisp-remote plugin. The audit daemon may be linked with tcp_wrappers to control which machines can connect. If this is the case, you can add an entry to hosts.allow and deny.
auditd.conf(5), auditd-plugins(5), ausearch(8), aureport(8), auditctl(8), augenrules(8), audit.rules(7).
Steve Grubb
scontrol(1)                      Slurm Commands                      scontrol(1)
scontrol - view or modify Slurm configuration and state.
scontrol [OPTIONS...] [COMMAND...]
scontrol is used to view or modify Slurm configuration including: job, job step, node, partition, reservation, and overall system configuration. Most of the commands can only be executed by user root or an Administrator. If an attempt to view or modify configuration information is made by an unauthorized user, an error message will be printed and the requested action will not occur.  If no command is entered on the execute line, scontrol will operate in an interactive mode and prompt for input. It will continue prompting for input and executing commands until explicitly terminated. If a command is entered on the execute line, scontrol will execute that command and terminate. All commands and options are case-insensitive, although node names, partition names, and reservation names are case-sensitive (node names "LX" and "lx" are distinct). All commands and options can be abbreviated to the extent that the specification is unique. A modified Slurm configuration can be written to a file using the scontrol write config command. The resulting file will be named using the convention "slurm.conf.<datetime>" and located in the same directory as the original "slurm.conf" file. The directory containing the original slurm.conf must be writable for this to occur.
-a, --all When the show command is used, then display all partitions, their jobs and jobs steps. This causes information to be displayed about partitions that are configured as hidden and partitions that are unavailable to user's group.
-d, --details Causes the show command to provide additional details where available.
--federation Report jobs from federation if a member of one.
-F, --future Report nodes in FUTURE state.
-h, --help Print a help message describing the usage of scontrol.
--hide Do not display information about hidden partitions, their jobs and job steps.  By default, neither partitions that are configured as hidden nor those partitions unavailable to user's group will be displayed (i.e. this is the default behavior).
--local Show only information local to this cluster. Ignore other clusters in the federated if a member of one. Overrides --federation.
-M, --clusters=<string> The cluster to issue commands to. Only one cluster name may be specified.  Note that the SlurmDBD must be up for this option to work properly.  This option implicitly sets the --local option.
-o, --oneliner Print information one line per record.
-Q, --quiet Print no warning or informational messages, only fatal error messages.
--sibling Show all sibling jobs on a federated cluster. Implies --federation.
-u, --uid=<uid> Attempt to update a job as user <uid> instead of the invoking user id.
-v, --verbose Print detailed event logging. Multiple -v's will further increase the verbosity of logging. By default only errors will be displayed.
-V , --version Print version information and exit.
COMMANDS
abort  Instruct the Slurm controller to terminate immediately and generate a core file.  See "man slurmctld" for information about where the core file will be written.
cancel_reboot <NodeList> Cancel pending reboots on nodes. The node will be undrain'ed and the reason cleared if the node was drained by an ASAP reboot.
cluster CLUSTER_NAME The cluster to issue commands to. Only one cluster name may be specified.
create SPECIFICATION Create a new partition or reservation.  See the full list of parameters below.  Include the tag "res" to create a reservation without specifying a reservation name.
completing Display all jobs in a COMPLETING state along with associated nodes in either a COMPLETING or DOWN state.
delete SPECIFICATION Delete the entry with the specified SPECIFICATION.  The two SPECIFICATION choices are PartitionName=<name> and Reservation=<name>. Reservations and partitions should have no associated jobs at the time of their deletion (modify the jobs first).  If the specified partition is in use, the request is denied.
errnumstr ERRNO Given a Slurm error number, return a descriptive string.
fsdampeningfactor FACTOR Set the FairShareDampeningFactor in slurmctld.
help   Display a description of scontrol options and commands.
hold job_list Prevent a pending job from being started (sets its priority to 0). Use the release command to permit the job to be scheduled.  The job_list argument is a comma separated list of job IDs OR "jobname=" with the job's name, which will attempt to hold all jobs having that name.  Note that when a job is held by a system administrator using the hold command, only a system administrator may release the job for execution (also see the uhold command). When the job is held by its owner, it may also be released by the job's owner.  Additionally, attempting to hold a running job will have not suspend or cancel it. But, it will set the job priority to 0 and update the job reason field, which would hold the job if it was requeued at a later time.
notify job_id message Send a message to standard error of the salloc or srun command or batch job associated with the specified job_id.
pidinfo proc_id Print the Slurm job id and scheduled termination time corresponding to the supplied process id, proc_id, on the current node.  This will work only with processes on node on which scontrol is run, and only for those processes spawned by Slurm and their descendants.
listpids [job_id[.step_id]] [NodeName] Print a listing of the process IDs in a job step (if JOBID.STEPID is provided), or all of the job steps in a job (if job_id is provided), or all of the job steps in all of the jobs on the local node (if job_id is not provided or job_id is "*").  This will work only with processes on the node on which scontrol is run, and only for those processes spawned by Slurm and their descendants. Note that some Slurm configurations (ProctrackType value of pgid) are unable to identify all processes associated with a job or job step.
Note that the NodeName option is only really useful when you have multiple slurmd daemons running on the same host machine. Multiple slurmd daemons on one host are, in general, only used by Slurm developers.
ping   Ping the primary and secondary slurmctld daemon and report if they are responding.
reboot [ASAP] [nextstate=<RESUME|DOWN>] [reason=<reason>] <ALL|NodeList> Reboot the nodes in the system when they become idle using the RebootProgram as configured in Slurm's slurm.conf file.  Each node will have the "REBOOT" flag added to its node state.  After a node reboots and the slurmd daemon starts up again, the HealthCheckProgram will run once. Then, the slurmd daemon will register itself with the slurmctld daemon and the "REBOOT" flag will be cleared.  The node's "DRAIN" state flag will be cleared if the reboot was "ASAP", nextstate=resume or down.  The "ASAP" option adds the "DRAIN" flag to each node's state, preventing additional jobs from running on the node so it can be rebooted and returned to service "As Soon As Possible" (i.e. ASAP).  "ASAP" will also set the node reason to "Reboot ASAP" if the "reason" option isn't specified.  If the "nextstate" option is specified as "DOWN", then the node will remain in a down state after rebooting. If "nextstate" is specified as "RESUME", then the nodes will resume as normal and the node's reason and "DRAIN" state will be cleared.  Resuming nodes will be considered as available in backfill future scheduling and won't be replaced by idle nodes in a reservation.  The "reason" option sets each node's reason to a user-defined message.  A default reason of "reboot requested" is set if no other reason is set on the node.  The reason will be appended with "reboot issued" when the reboot is issued and "reboot complete" when the node registers and has a "nextstate" of "DOWN".  You must specify either a list of nodes or that ALL nodes are to be rebooted.  NOTE: By default, this command does not prevent additional jobs from being scheduled on any nodes before reboot.  To do this, you can either use the "ASAP" option or explicitly drain the nodes beforehand.  You can alternately create an advanced reservation to prevent additional jobs from being initiated on nodes to be rebooted.  Pending reboots can be cancelled by using "scontrol cancel_reboot <node>" or setting the node state to "CANCEL_REBOOT".  A node will be marked "DOWN" if it doesn't reboot within ResumeTimeout.
reconfigure Instruct all Slurm daemons to re-read the configuration file. This command does not restart the daemons.  This mechanism would be used to modify configuration parameters (Epilog, Prolog, SlurmctldLogFile, SlurmdLogFile, etc.).  The Slurm controller (slurmctld) forwards the request to all other daemons (slurmd daemon on each compute node). Running jobs continue execution. Most configuration parameters can be changed by just running this command, however, Slurm daemons should be shutdown and restarted if any of these parameters are to be changed: AuthType, ControlMach, PluginDir, StateSaveLocation, SlurmctldHost, SlurmctldPort, or SlurmdPort. The slurmctld daemon and all slurmd daemons must be restarted if nodes are added to or removed from the cluster.
release job_list Release a previously held job to begin execution.  The job_list argument is a comma separated list of job IDs OR "jobname=" with the job's name, which will attempt to hold all jobs having that name.  Also see hold.
requeue [option] job_list Requeue a running, suspended or finished Slurm batch job into pending state.  The job_list argument is a comma separated list of job IDs.  The command accepts the following option:
Incomplete Operate only on jobs (or tasks of a job array) which have not completed.  Specifically only jobs in the following states will be requeued: CONFIGURING, RUNNING, STOPPED or SUSPENDED.
requeuehold [option] job_list Requeue a running, suspended or finished Slurm batch job into pending state, moreover the job is put in held state (priority zero).  The job_list argument is a comma separated list of job IDs.  A held job can be released using scontrol to reset its priority (e.g.  "scontrol release <job_id>"). The command accepts the following options:
State=SpecialExit The "SpecialExit" keyword specifies that the job has to be put in a special state JOB_SPECIAL_EXIT.  The "scontrol show job" command will display the JobState as SPECIAL_EXIT, while the "squeue" command as SE.
resume job_list Resume a previously suspended job.  The job_list argument is a comma separated list of job IDs.  Also see suspend.
NOTE: A suspended job releases its CPUs for allocation to other jobs.  Resuming a previously suspended job may result in multiple jobs being allocated the same CPUs, which could trigger gang scheduling with some configurations or severe degradation in performance with other configurations.  Use of the scancel command to send SIGSTOP and SIGCONT signals would stop a job without releasing its CPUs for allocation to other jobs and would be a preferable mechanism in many cases.  If performing system maintenance you may want to use suspend/resume in the following way. Before suspending set all nodes to draining or set all partitions to down so that no new jobs can be scheduled. Then suspend jobs. Once maintenance is done resume jobs then resume nodes and/or set all partitions back to up.  Use with caution.
schedloglevel LEVEL Enable or disable scheduler logging.  LEVEL may be "0", "1", "disable" or "enable". "0" has the same effect as "disable". "1" has the same effect as "enable".  This value is temporary and will be overwritten when the slurmctld daemon reads the slurm.conf configuration file (e.g. when the daemon is restarted or scontrol reconfigure is executed) if the SlurmSchedLogLevel parameter is present.
setdebug LEVEL Change the debug level of the slurmctld daemon.  LEVEL may be an integer value between zero and nine (using the same values as SlurmctldDebug in the slurm.conf file) or the name of the most detailed message type to be printed: "quiet", "fatal", "error", "info", "verbose", "debug", "debug2", "debug3", "debug4", or "debug5".  This value is temporary and will be overwritten whenever the slurmctld daemon reads the slurm.conf configuration file (e.g. when the daemon is restarted or scontrol reconfigure is executed).
setdebugflags [+|-]FLAG Add or remove DebugFlags of the slurmctld daemon.  See "man slurm.conf" for a list of supported DebugFlags.  NOTE: Changing the value of some DebugFlags will have no effect without restarting the slurmctld daemon, which would set DebugFlags based upon the contents of the slurm.conf configuration file.
show ENTITY ID or
shutdown OPTION Instruct Slurm daemons to save current state and terminate.  By default, the Slurm controller (slurmctld) forwards the request all other daemons (slurmd daemon on each compute node).  An OPTION of slurmctld or controller results in only the slurmctld daemon being shutdown and the slurmd daemons remaining active.
suspend job_list Suspend a running job.  The job_list argument is a comma separated list of job IDs.  Use the resume command to resume its execution. User processes must stop on receipt of SIGSTOP signal and resume upon receipt of SIGCONT for this operation to be effective.  Not all architectures and configurations support job suspension.  If a suspended job is requeued, it will be placed in a held state.  The time a job is suspended will not count against a job's time limit. Only an operator, administrator, SlurmUser, or root can suspend jobs.
takeover [INDEX] Instruct one of Slurm's backup controllers (slurmctld) to take over system control. By default the first backup controller (INDEX=1) requests control from the primary and waits for its termination. After that, it switches from backup mode to controller mode. If primary controller can not be contacted, it directly switches to controller mode. This can be used to speed up the Slurm controller fail-over mechanism when the primary node is down.  This can be used to minimize disruption if the computer executing the primary Slurm controller is scheduled down.  (Note: Slurm's primary controller will take the control back at startup.)
top job_list Move the specified job IDs to the top of the queue of jobs belonging to the identical user ID, partition name, account, and QOS.  The job_list argument is a comma separated ordered list of job IDs.  Any job not matching all of those fields will not be effected.  Only jobs submitted to a single partition will be effected.  This operation changes the order of jobs by adjusting job nice values.  The net effect on that user's throughput will be negligible to slightly negative.  This operation is disabled by default for non-privileged (non-operator, admin, SlurmUser, or root) users. This operation may be enabled for non-privileged users by the system administrator by including the option "enable_user_top" in the SchedulerParameters configuration parameter.
token [lifespan=<lifespan>] [username=<username>] Return an auth token which can be used to support JWT authentication if AuthAltTypes=auth/jwt has been enabled on the system.  Supports two optional arguments. lifespan= may be used to specify the token's lifespan. username (only available to SlurmUser/root) may be used to request a token for a different username.
uhold job_list Prevent a pending job from being started (sets its priority to 0). The job_list argument is a space separated list of job IDs or job names.  Use the release command to permit the job to be scheduled. This command is designed for a system administrator to hold a job so that the job owner may release it rather than requiring the intervention of a system administrator (also see the hold command).
update SPECIFICATION Update job, step, node, partition, or reservation configuration per the supplied specification. SPECIFICATION is in the same format as the Slurm configuration file and the output of the show command described above. It may be desirable to execute the show command (described above) on the specific entity you want to update, then use cut-and-paste tools to enter updated configuration values to the update. Note that while most configuration values can be changed using this command, not all can be changed using this mechanism. In particular, the hardware configuration of a node or the physical addition or removal of nodes from the cluster may only be accomplished through editing the Slurm configuration file and executing the reconfigure command (described above).
version Display the version number of scontrol being executed.
wait_job job_id Wait until a job and all of its nodes are ready for use or the job has entered some termination state. This option is particularly useful in the Slurm Prolog or in the batch script itself if nodes are powered down and restarted automatically as needed.
NOTE: Don't use scontrol wait_job in PrologCtld or Prolog with PrologFlags=Alloc as this will result in deadlock.
write batch_script job_id optional_filename Write the batch script for a given job_id to a file or to stdout. The file will default to slurm-<job_id>.sh if the optional filename argument is not given. The script will be written to stdout if - is given instead of a filename.  The batch script can only be retrieved by an admin or operator, or by the owner of the job.
write config optional_filename Write the current configuration to a file with the naming convention of "slurm.conf.<datetime>" in the same directory as the original slurm.conf file.  If a filename is given that file location with a .<datetime> suffix is created.
INTERACTIVE COMMANDS NOTE: All commands listed below can be used in the interactive mode, but NOT on the initial command line.
all    Show all partitions, their jobs and jobs steps. This causes information to be displayed about partitions that are configured as hidden and partitions that are unavailable to user's group.
details Causes the show command to provide additional details where available.  Job information will include CPUs and NUMA memory allocated on each node.  Note that on computers with hyperthreading enabled and Slurm configured to allocate cores, each listed CPU represents one physical core.  Each hyperthread on that core can be allocated a separate task, so a job's CPU count and task count may differ.  See the --cpu-bind and --mem-bind option descriptions in srun man pages for more information.  The details option is currently only supported for the show job command.
exit   Terminate scontrol interactive session.
hide   Do not display partition, job or jobs step information for partitions that are configured as hidden or partitions that are unavailable to the user's group.  This is the default behavior.
oneliner Print information one line per record.
quiet  Print no warning or informational messages, only fatal error messages.
quit   Terminate the execution of scontrol.
verbose Print detailed event logging.  This includes time-stamps on data structures, record counts, etc.
!!     Repeat the last command executed.
SPECIFICATIONS FOR UPDATE COMMAND, JOBS
Note that update requests done by either root, SlurmUser or Administrators are not subject to certain restrictions. For instance, if an Administrator changes the QOS on a pending job, certain limits such as the TimeLimit will not be changed automatically as changes made by the Administrators are allowed to violate these restrictions.
Account=<account> Account name to be changed for this job's resource use.  Value may be cleared with blank data value, "Account=".
AdminComment=<spec> Arbitrary descriptive string. Can only be set by a Slurm administrator.
ArrayTaskThrottle=<count> Specify the maximum number of tasks in a job array that can execute at the same time.  Set the count to zero in order to eliminate any limit.  The task throttle count for a job array is reported as part of its ArrayTaskId field, preceded with a percent sign.  For example "ArrayTaskId=1-10%2" indicates the maximum number of running tasks is limited to 2.
BurstBuffer=<spec> Burst buffer specification to be changed for this job's resource use.  Value may be cleared with blank data value, "BurstBuffer=". Format is burst buffer plugin specific.
Clusters=<spec> Specifies the clusters that the federated job can run on.
ClusterFeatures=<spec> Specifies features that a federated cluster must have to have a sibling job submitted to it. Slurm will attempt to submit a sibling job to a cluster if it has at least one of the specified features.
Comment=<spec> Arbitrary descriptive string.
Contiguous=<yes|no> Set the job's requirement for contiguous (consecutive) nodes to be allocated.  Possible values are "YES" and "NO".  Only the Slurm administrator or root can change this parameter.
CoreSpec=<count> Number of cores to reserve per node for system use.  The job will be charged for these cores, but be unable to use them.  Will be reported as "*" if not constrained.
CPUsPerTask=<count> Change the CPUsPerTask job's value.
Deadline=<time_spec> It accepts times of the form HH:MM:SS to specify a deadline to a job at a specific time of day (seconds are optional).  You may also specify midnight, noon, fika (3 PM) or teatime (4 PM) and you can have a time-of-day suffixed with AM or PM for a deadline in the morning or the evening.  You can specify a deadline for the job with a date of the form MMDDYY or MM/DD/YY or MM.DD.YY, or a date and time as YYYY-MM-DD[THH:MM[:SS]].  You can also give times like now + count time-units, where the time-units can be seconds (default), minutes, hours, days, or weeks and you can tell Slurm to put a deadline for tomorrow with the keyword tomorrow.  The specified deadline must be later than the current time.  Only pending jobs can have the deadline updated.  Only the Slurm administrator or root can change this parameter.
DelayBoot=<time_spec> Change the time to decide whether to reboot nodes in order to satisfy job's feature specification if the job has been eligible to run for less than this time period. See salloc/sbatch man pages option --delay-boot.
Dependency=<dependency_list> Defer job's initiation until specified job dependency specification is satisfied.  Cancel dependency with an empty dependency_list (e.g. "Dependency=").  <dependency_list> is of the form <type:job_id[:job_id][,type:job_id[:job_id]]>.  Many jobs can share the same dependency and these jobs may even belong to different  users.
after:job_id[:jobid...] This job can begin execution after the specified jobs have begun execution or been canceled.
singleton This job can begin execution after any previously launched jobs sharing the same job name and user have terminated. In other words, only one job by that name and owned by that user can be running or suspended at any point in time.
EligibleTime=<time_spec> See StartTime.
EndTime The time the job is expected to terminate based on the job's time limit.  When the job ends sooner, this field will be updated with the actual end time.
ExcNodeList=<nodes> Set the job's list of excluded node. Multiple node names may be specified using simple node range expressions (e.g. "lx[10-20]"). Value may be cleared with blank data value, "ExcNodeList=".
Features=<features> Set the job's required node features.  The list of features may include multiple feature names separated by ampersand (AND) and/or vertical bar (OR) operators.  For example: Features="opteron&video" or Features="fast|faster".  In the first example, only nodes having both the feature "opteron" AND the feature "video" will be used.  There is no mechanism to specify that you want one node with feature "opteron" and another node with feature "video" in case no node has both features.  If only one of a set of possible options should be used for all allocated nodes, then use the OR operator and enclose the options within square brackets.  For example: "Features=[rack1|rack2|rack3|rack4]" might be used to specify that all nodes must be allocated on a single rack of the cluster, but any of those four racks can be used.  A request can also specify the number of nodes needed with some feature by appending an asterisk and count after the feature name.  For example "Features=graphics*4" indicates that at least four allocated nodes must have the feature "graphics."  Parenthesis are also supported for features to be ANDed together.  For example "Features=[(knl&a2a&flat)*4&haswell*2]" indicates the resource allocation should include 4 nodes with ALL of the features "knl", "a2a", and "flat" plus 2 nodes with the feature "haswell". Constraints with node counts may only be combined with AND operators.  Value may be cleared with blank data value, for example "Features=".