1CONDOR_Q(1) HTCondor Manual CONDOR_Q(1)
2
6 condor_q - HTCondor Manual
7 Display information about jobs in queue
9
13 condor_q [-help [Universe | State] ]
14 condor_q [-debug ] [general options ] [restriction list ] [output op‐
16 tions ] [analyze options ]
17
19 condor_q displays information about jobs in the HTCondor job queue. By
20 default, condor_q queries the local job queue, but this behavior may be
21 modified by specifying one of the general options.
22 As of version 8.5.2, condor_q defaults to querying only the current
24 user's jobs. This default is overridden when the restriction list has
25 usernames and/or job ids, when the -submitter or -allusers arguments
26 are specified, or when the current user is a queue superuser. It can
27 also be overridden by setting the CONDOR_Q_ONLY_MY_JOBS configuration
28 macro to False.
29 As of version 8.5.6, condor_q defaults to batch-mode output (see -batch
31 in the Options section below). The old behavior can be obtained by
32 specifying -nobatch on the command line. To change the default back to
33 its pre-8.5.6 value, set the new configuration variable CON‐
34 DOR_Q_DASH_BATCH_IS_DEFAULT to False.
35
37 As of version 8.5.6, condor_q defaults to displaying information about
38 batches of jobs, rather than individual jobs. The intention is that
39 this will be a more useful, and user-friendly, format for users with
40 large numbers of jobs in the queue. Ideally, users will specify mean‐
41 ingful batch names for their jobs, to make it easier to keep track of
42 related jobs.
43 (For information about specifying batch names for your jobs, see the
45 condor_submit and condor_submit_dag manual pages.)
46 A batch of jobs is defined as follows:
48 • An entire workflow (a DAG or hierarchy of nested DAGs) (note that
50 condor_dagman now specifies a default batch name for all jobs in a
51 given workflow)
52 • All jobs in a single cluster
54 • All jobs submitted by a single user that have the same executable
56 specified in their submit file (unless submitted with different batch
57 names)
58 • All jobs submitted by a single user that have the same batch name
60 specified in their submit file or on the condor_submit or condor_sub‐
61 mit_dag command line.
62
64 There are many output options that modify the output generated by con‐
65 dor_q. The effects of these options, and the meanings of the various
66 output data, are described below.
67 Output options
69 If the -long option is specified, condor_q displays a long description
70 of the queried jobs by printing the entire job ClassAd for all jobs
71 matching the restrictions, if any. Individual attributes of the job
72 ClassAd can be displayed by means of the -format option, which displays
73 attributes with a printf(3) format, or with the -autoformat option.
74 Multiple -format options may be specified in the option list to display
75 several attributes of the job.
76 For most output options (except as specified), the last line of con‐
78 dor_q output contains a summary of the queue: the total number of jobs,
79 and the number of jobs in the completed, removed, idle, running, held
80 and suspended states.
81 If no output options are specified, condor_q now defaults to batch
83 mode, and displays the following columns of information, with one line
84 of output per batch of jobs:
85 OWNER, BATCH_NAME, SUBMITTED, DONE, RUN, IDLE, [HOLD,] TOTAL, JOB_IDS
87 Note that the HOLD column is only shown if there are held jobs in the
89 output or if there are no jobs in the output.
90 If the -nobatch option is specified, condor_q displays the following
92 columns of information, with one line of output per job:
93 ID, OWNER, SUBMITTED, RUN_TIME, ST, PRI, SIZE, CMD
95 If the -dag option is specified (in conjunction with -nobatch), con‐
97 dor_q displays the following columns of information, with one line of
98 output per job; the owner is shown only for top-level jobs, and for all
99 other jobs (including sub-DAGs) the node name is shown:
100 ID, OWNER/NODENAME, SUBMITTED, RUN_TIME, ST, PRI, SIZE, CMD
102 If the -run option is specified (in conjunction with -nobatch), con‐
104 dor_q displays the following columns of information, with one line of
105 output per running job:
106 ID, OWNER, SUBMITTED, RUN_TIME, HOST(S)
108 Also note that the -run option disables output of the totals line.
110 If the -grid option is specified, condor_q displays the following col‐
112 umns of information, with one line of output per job:
113 ID, OWNER, STATUS, GRID->MANAGER, HOST, GRID_JOB_ID
115 If the -grid:ec2 option is specified, condor_q displays the following
117 columns of information, with one line of output per job:
118 ID, OWNER, STATUS, INSTANCE ID, CMD
120 If the -goodput option is specified, condor_q displays the following
122 columns of information, with one line of output per job:
123 ID, OWNER, SUBMITTED, RUN_TIME, GOODPUT, CPU_UTIL, Mb/s
125 If the -io option is specified, condor_q displays the following columns
127 of information, with one line of output per job:
128 ID, OWNER, RUNS, ST, INPUT, OUTPUT, RATE, MISC
130 If the -cputime option is specified (in conjunction with -nobatch),
132 condor_q displays the following columns of information, with one line
133 of output per job:
134 ID, OWNER, SUBMITTED, CPU_TIME, ST, PRI, SIZE, CMD
136 If the -hold option is specified, condor_q displays the following col‐
138 umns of information, with one line of output per job:
139 ID, OWNER, HELD_SINCE, HOLD_REASON
141 If the -totals option is specified, condor_q displays only one line of
143 output no matter how many jobs and batches of jobs are in the queue.
144 That line of output contains the total number of jobs, and the number
145 of jobs in the completed, removed, idle, running, held and suspended
146 states.
147 Output data
149 The available output data are as follows:
150 ID (Non-batch mode only) The cluster/process id of the HTCondor
152 job.
153 OWNER The owner of the job or batch of jobs.
155 OWNER/NODENAME
157 (-dag only) The owner of a job or the DAG node name of the
158 job.
159 BATCH_NAME
161 (Batch mode only) The batch name of the job or batch of jobs.
162 SUBMITTED
164 The month, day, hour, and minute the job was submitted to the
165 queue.
166 DONE (Batch mode only) The number of job procs that are done, but
168 still in the queue.
169 RUN (Batch mode only) The number of job procs that are running.
171 IDLE (Batch mode only) The number of job procs that are in the
173 queue but idle.
174 HOLD (Batch mode only) The number of job procs that are in the
176 queue but held.
177 TOTAL (Batch mode only) The total number of job procs in the queue,
179 unless the batch is a DAG, in which case this is the total
180 number of clusters in the queue. Note: for non-DAG batches,
181 the TOTAL column contains correct values only in version
182 8.5.7 and later.
183 JOB_IDS
185 (Batch mode only) The range of job IDs belonging to the
186 batch.
187 RUN_TIME
189 (Non-batch mode only) Wall-clock time accumulated by the job
190 to date in days, hours, minutes, and seconds.
191 ST (Non-batch mode only) Current status of the job, which varies
193 somewhat according to the job universe and the timing of up‐
194 dates. H = on hold, R = running, I = idle (waiting for a ma‐
195 chine to execute on), C = completed, X = removed, S = sus‐
196 pended (execution of a running job temporarily suspended on
197 execute node), < = transferring input (or queued to do so),
198 and > = transferring output (or queued to do so).
199 PRI (Non-batch mode only) User specified priority of the job,
201 displayed as an integer, with higher numbers corresponding to
202 better priority.
203 SIZE (Non-batch mode only) The peak amount of memory in Mbytes
205 consumed by the job; note this value is only refreshed peri‐
206 odically. The actual value reported is taken from the job
207 ClassAd attribute MemoryUsage if this attribute is defined,
208 and from job attribute ImageSize otherwise.
209 CMD (Non-batch mode only) The name of the executable. For EC2
211 jobs, this field is arbitrary.
212 HOST(S)
214 (-run only) The host where the job is running.
215 STATUS (-grid only) The state that HTCondor believes the job is in.
217 Possible values are grid-type specific, but include:
218 PENDING
220 The job is waiting for resources to become avail‐
221 able in order to run.
222 ACTIVE The job has received resources, and the applica‐
224 tion is executing.
225 FAILED The job terminated before completion because of an
227 error, user-triggered cancel, or system-triggered
228 cancel.
229 DONE The job completed successfully.
231 SUSPENDED
233 The job has been suspended. Resources which were
234 allocated for this job may have been released due
235 to a scheduler-specific reason.
236 UNSUBMITTED
238 The job has not been submitted to the scheduler
239 yet, pending the reception of the GLOBUS_GRAM_PRO‐
240 TOCOL_JOB_SIGNAL_COMMIT_REQUEST signal from a
241 client.
242 STAGE_IN
244 The job manager is staging in files, in order to
245 run the job.
246 STAGE_OUT
248 The job manager is staging out files generated by
249 the job.
250 UNKNOWN
252 Unknown
253 GRID->MANAGER
255 (-grid only) A guess at what remote batch system is running
256 the job. It is a guess, because HTCondor looks at the Globus
257 jobmanager contact string to attempt identification. If the
258 value is fork, the job is running on the remote host without
259 a jobmanager. Values may also be condor, lsf, or pbs.
260 HOST (-grid only) The host to which the job was submitted.
262 GRID_JOB_ID
264 (-grid only) (More information needed here.)
265 INSTANCE ID
267 (-grid:ec2 only) Usually EC2 instance ID; may be blank or the
268 client token, depending on job progress.
269 GOODPUT
271 (-goodput only) The percentage of RUN_TIME for this job which
272 has been saved in a checkpoint. A low GOODPUT value indicates
273 that the job is failing to checkpoint. If a job has not yet
274 attempted a checkpoint, this column contains [?????].
275 CPU_UTIL
277 (-goodput only) The ratio of CPU_TIME to RUN_TIME for check‐
278 pointed work. A low CPU_UTIL indicates that the job is not
279 running efficiently, perhaps because it is I/O bound or be‐
280 cause the job requires more memory than available on the re‐
281 mote workstations. If the job has not (yet) checkpointed,
282 this column contains [??????].
283 Mb/s (-goodput only) The network usage of this job, in Megabits
285 per second of run-time. READ The total number of bytes the
286 application has read from files and sockets. WRITE The total
287 number of bytes the application has written to files and
288 sockets. SEEK The total number of seek operations the appli‐
289 cation has performed on files. XPUT The effective throughput
290 (average bytes read and written per second) from the applica‐
291 tion's point of view. BUFSIZE The maximum number of bytes to
292 be buffered per file. BLOCKSIZE The desired block size for
293 large data transfers. These fields are updated when a job
294 produces a checkpoint or completes. If a job has not yet pro‐
295 duced a checkpoint, this information is not available.
296 INPUT (-io only) For standard universe, FileReadBytes; otherwise,
298 BytesRecvd.
299 OUTPUT (-io only) For standard universe, FileWriteBytes; otherwise,
301 BytesSent.
302 RATE (-io only) For standard universe, FileReadBytes+FileWrite‐
304 Bytes; otherwise, BytesRecvd+BytesSent.
305 MISC (-io only) JobUniverse.
307 CPU_TIME
309 (-cputime only) The remote CPU time accumulated by the job to
310 date (which has been stored in a checkpoint) in days, hours,
311 minutes, and seconds. (If the job is currently running, time
312 accumulated during the current run is not shown. If the job
313 has not produced a checkpoint, this column contains
314 0+00:00:00.)
315 HELD_SINCE
317 (-hold only) Month, day, hour and minute at which the job was
318 held.
319 HOLD_REASON
321 (-hold only) The hold reason for the job.
322 Analyze
324 The -analyze or -better-analyze options can be used to determine why
325 certain jobs are not running by performing an analysis on a per machine
326 basis for each machine in the pool. The reasons can vary among failed
327 constraints, insufficient priority, resource owner preferences and pre‐
328 vention of preemption by the PREEMPTION_REQUIREMENTS
329 expression. If the analyze option -verbose is specified along with
330 the -analyze option, the reason for failure is displayed on a per ma‐
331 chine basis. -better-analyze differs from -analyze in that it will do
332 matchmaking analysis on jobs even if they are currently running, or if
333 the reason they are not running is not due to matchmaking. -better-ana‐
334 lyze also produces more thorough analysis of complex Requirements and
335 shows the values of relevant job ClassAd attributes. When only a single
336 machine is being analyzed via -machine or -mconstraint, the values of
337 relevant attributes of the machine ClassAd are also displayed.
338
340 To restrict the display to jobs of interest, a list of zero or more re‐
341 striction options may be supplied. Each restriction may be one of:
342 • cluster.process, which matches jobs which belong to the specified
344 cluster and have the specified process number;
345 • cluster (without a process), which matches all jobs belonging to the
347 specified cluster;
348 • owner, which matches all jobs owned by the specified owner;
350 • -constraint expression, which matches all jobs that satisfy the spec‐
352 ified ClassAd expression;
353 • -unmatchable expression, which matches all jobs that do not match any
355 slot that would be considered by -better-analyze ;
356 • -allusers, which overrides the default restriction of only matching
358 jobs submitted by the current user.
359 If cluster or cluster.process is specified, and the job matching that
361 restriction is a condor_dagman job, information for all jobs of that
362 DAG is displayed in batch mode (in non-batch mode, only the condor_dag‐
363 man job itself is displayed).
364 If no owner restrictions are present, the job matches the restriction
366 list if it matches at least one restriction in the list. If owner re‐
367 strictions are present, the job matches the list if it matches one of
368 the owner restrictions and at least one non-owner restriction.
369
371 -debug Causes debugging information to be sent to stderr, based on
372 the value of the configuration variable TOOL_DEBUG.
373 -batch (output option) Show a single line of progress information
375 for a batch of jobs, where a batch is defined as follows:
376 • An entire workflow (a DAG or hierarchy of nested DAGs)
378 • All jobs in a single cluster
380 • All jobs submitted by a single user that have the same exe‐
382 cutable specified in their submit file
383 • All jobs submitted by a single user that have the same
385 batch name specified in their submit file or on the con‐
386 dor_submit or condor_submit_dag command line.
387 Also change the output columns as noted above.
389 Note that, as of version 8.5.6, -batch is the default, unless
391 the CONDOR_Q_DASH_BATCH_IS_DEFAULT configuration variable is
392 set to False.
393 -nobatch
395 (output option) Show a line for each job (turn off the -batch
396 option).
397 -global
399 (general option) Queries all job queues in the pool.
400 -submitter submitter
402 (general option) List jobs of a specific submitter in the en‐
403 tire pool, not just for a single condor_schedd.
404 -name name
406 (general option) Query only the job queue of the named con‐
407 dor_schedd daemon.
408 -pool centralmanagerhostname[:portnumber]
410 (general option) Use the centralmanagerhostname as the cen‐
411 tral manager to locate condor_schedd daemons. The default is
412 the COLLECTOR_HOST, as specified in the configuration.
413 -jobads file
415 (general option) Display jobs from a list of ClassAds from a
416 file, instead of the real ClassAds from the condor_schedd
417 daemon. This is most useful for debugging purposes. The Clas‐
418 sAds appear as if condor_q -long is used with the header
419 stripped out.
420 -userlog file
422 (general option) Display jobs, with job information coming
423 from a job event log, instead of from the real ClassAds from
424 the condor_schedd daemon. This is most useful for automated
425 testing of the status of jobs known to be in the given job
426 event log, because it reduces the load on the condor_schedd.
427 A job event log does not contain all of the job information,
428 so some fields in the normal output of condor_q will be
429 blank.
430 -autocluster
432 (output option) Output condor_schedd daemon auto cluster in‐
433 formation. For each auto cluster, output the unique ID of the
434 auto cluster along with the number of jobs in that auto clus‐
435 ter. This option is intended to be used together with the
436 -long option to output the ClassAds representing auto clus‐
437 ters. The ClassAds can then be used to identify or classify
438 the demand for sets of machine resources, which will be use‐
439 ful in the on-demand creation of execute nodes for glidein
440 services.
441 -cputime
443 (output option) Instead of wall-clock allocation time
444 (RUN_TIME), display remote CPU time accumulated by the job to
445 date in days, hours, minutes, and seconds. If the job is cur‐
446 rently running, time accumulated during the current run is
447 not shown. Note that this option has no effect unless used in
448 conjunction with -nobatch.
449 -currentrun
451 (output option) Normally, RUN_TIME contains all the time ac‐
452 cumulated during the current run plus all previous runs. If
453 this option is specified, RUN_TIME only displays the time ac‐
454 cumulated so far on this current run.
455 -dag (output option) Display DAG node jobs under their DAGMan in‐
457 stance. Child nodes are listed using indentation to show the
458 structure of the DAG. Note that this option has no effect un‐
459 less used in conjunction with -nobatch.
460 -expert
462 (output option) Display shorter error messages.
463 -grid (output option) Get information only about jobs submitted to
465 grid resources.
466 -grid:ec2
468 (output option) Get information only about jobs submitted to
469 grid resources and display it in a format better-suited for
470 EC2 than the default.
471 -goodput
473 (output option) Display job goodput statistics.
474 -help [Universe | State]
476 (output option) Print usage info, and, optionally, addition‐
477 ally print job universes or job states.
478 -hold (output option) Get information about jobs in the hold state.
480 Also displays the time the job was placed into the hold state
481 and the reason why the job was placed in the hold state.
482 -limit Number
484 (output option) Limit the number of items output to Number.
485 -io (output option) Display job input/output summaries.
487 -long (output option) Display entire job ClassAds in long format
489 (one attribute per line).
490 -run (output option) Get information about running jobs. Note that
492 this option has no effect unless used in conjunction with
493 -nobatch.
494 -stream-results
496 (output option) Display results as jobs are fetched from the
497 job queue rather than storing results in memory until all
498 jobs have been fetched. This can reduce memory consumption
499 when fetching large numbers of jobs, but if condor_q is
500 paused while displaying results, this could result in a time‐
501 out in communication with condor_schedd.
502 -totals
504 (output option) Display only the totals.
505 -version
507 (output option) Print the HTCondor version and exit.
508 -wide (output option) If this option is specified, and the command
510 portion of the output would cause the output to extend beyond
511 80 columns, display beyond the 80 columns.
512 -xml (output option) Display entire job ClassAds in XML format.
514 The XML format is fully defined in the reference manual, ob‐
515 tained from the ClassAds web page, with a link at
516 http://htcondor.org/classad/classad.html.
517 -json (output option) Display entire job ClassAds in JSON format.
519 -attributes Attr1[,Attr2 ...]
521 (output option) Explicitly list the attributes, by name in a
522 comma separated list, which should be displayed when using
523 the -xml, -json or -long options. Limiting the number of at‐
524 tributes increases the efficiency of the query.
525 -format fmt attr
527 (output option) Display attribute or expression attr in for‐
528 mat fmt. To display the attribute or expression the format
529 must contain a single printf(3)-style conversion specifier.
530 Attributes must be from the job ClassAd. Expressions are
531 ClassAd expressions and may refer to attributes in the job
532 ClassAd. If the attribute is not present in a given ClassAd
533 and cannot be parsed as an expression, then the format option
534 will be silently skipped. %r prints the unevaluated, or raw
535 values. The conversion specifier must match the type of the
536 attribute or expression. %s is suitable for strings such as
537 Owner, %d for integers such as ClusterId, and %f for floating
538 point numbers such as RemoteWallClockTime. %v identifies the
539 type of the attribute, and then prints the value in an appro‐
540 priate format. %V identifies the type of the attribute, and
541 then prints the value in an appropriate format as it would
542 appear in the -long format. As an example, strings used with
543 %V will have quote marks. An incorrect format will result in
544 undefined behavior. Do not use more than one conversion spec‐
545 ifier in a given format. More than one conversion specifier
546 will result in undefined behavior. To output multiple at‐
547 tributes repeat the -format option once for each desired at‐
548 tribute. Like printf(3) style formats, one may include other
549 text that will be reproduced directly. A format without any
550 conversion specifiers may be specified, but an attribute is
551 still required. Include a backslash followed by an 'n' to
552 specify a line break.
553 -autoformat[:jlhVr,tng] attr1 [attr2 ...] or -af[:jlhVr,tng] attr1
555 [attr2 ...]
556 (output option) Display attribute(s) or expression(s) format‐
557 ted in a default way according to attribute types. This op‐
558 tion takes an arbitrary number of attribute names as argu‐
559 ments, and prints out their values, with a space between each
560 value and a newline character after the last value. It is
561 like the -format option without format strings. This output
562 option does not work in conjunction with any of the options
563 -run, -currentrun, -hold, -grid, -goodput, or -io.
564 It is assumed that no attribute names begin with a dash char‐
566 acter, so that the next word that begins with dash is the
567 start of the next option. The autoformat option may be fol‐
568 lowed by a colon character and formatting qualifiers to devi‐
569 ate the output formatting from the default:
570 j print the job ID as the first field,
572 l label each field,
574 h print column headings before the first line of output,
576 V use %V rather than %v for formatting (string values are
578 quoted),
579 r print "raw", or unevaluated values,
581 , add a comma character after each field,
583 t add a tab character before each field instead of the de‐
585 fault space character,
586 n add a newline character after each field,
588 g add a newline character between ClassAds, and suppress spa‐
590 ces before each field.
591 Use -af:h to get tabular values with headings.
593 Use -af:lrng to get -long equivalent format.
595 The newline and comma characters may not be used together.
597 The l and h characters may not be used together.
598 -analyze[:<qual>]
600 (analyze option) Perform a matchmaking analysis on why the
601 requested jobs are not running. First a simple analysis de‐
602 termines if the job is not running due to not being in a
603 runnable state. If the job is in a runnable state, then this
604 option is equivalent to -better-analyze. <qual> is a comma
605 separated list containing one or more of
606 priority to consider user priority during the analysis
608 summary to show a one line summary for each job or machine
610 reverse to analyze machines, rather than jobs
611 -better-analyze[:<qual>]
614 (analyze option) Perform a more detailed matchmaking analysis
615 to determine how many resources are available to run the re‐
616 quested jobs. This option is never meaningful for Scheduler
617 universe jobs and only meaningful for grid universe jobs do‐
618 ing matchmaking. When this option is used in conjunction with
619 the -unmatchable option, The output will be a list of job ids
620 that don't match any of the available slots. <qual> is a
621 comma separated list containing one or more of
622 priority to consider user priority during the analysis
624 summary to show a one line summary for each job or machine
626 reverse to analyze machines, rather than jobs
627 -machine name
630 (analyze option) When doing matchmaking analysis, analyze
631 only machine ClassAds that have slot or machine names that
632 match the given name.
633 -mconstraint expression
635 (analyze option) When doing matchmaking analysis, match only
636 machine ClassAds which match the ClassAd expression con‐
637 straint.
638 -slotads file
640 (analyze option) When doing matchmaking analysis, use the ma‐
641 chine ClassAds from the file instead of the ones from the
642 condor_collector daemon. This is most useful for debugging
643 purposes. The ClassAds appear as if condor_status -long is
644 used.
645 -userprios file
647 (analyze option) When doing matchmaking analysis with prior‐
648 ity, read user priorities from the file rather than the ones
649 from the condor_negotiator daemon. This is most useful for
650 debugging purposes or to speed up analysis in situations
651 where the condor_negotiator daemon is slow to respond to con‐
652 dor_userprio requests. The file should be in the format pro‐
653 duced by condor_userprio -long.
654 -nouserprios
656 (analyze option) Do not consider user priority during the
657 analysis.
658 -reverse-analyze
660 (analyze option) Analyze machine requirements against jobs.
661 -verbose
663 (analyze option) When doing analysis, show progress and in‐
664 clude the names of specific machines in the output.
665
667 The default output from condor_q is formatted to be human readable, not
668 script readable. In an effort to make the output fit within 80 charac‐
669 ters, values in some fields might be truncated. Furthermore, the HTCon‐
670 dor Project can (and does) change the formatting of this default output
671 as we see fit. Therefore, any script that is attempting to parse data
672 from condor_q is strongly encouraged to use the -format option (de‐
673 scribed above, examples given below).
674 Although -analyze provides a very good first approximation, the ana‐
676 lyzer cannot diagnose all possible situations, because the analysis is
677 based on instantaneous and local information. Therefore, there are some
678 situations such as when several submitters are contending for re‐
679 sources, or if the pool is rapidly changing state which cannot be accu‐
680 rately diagnosed.
681 Options -goodput, -cputime, and -io are most useful for standard uni‐
683 verse jobs, since they rely on values computed when a job produces a
684 checkpoint.
685 It is possible to to hold jobs that are in the X state. To avoid this
687 it is best to construct a -constraint expression that option contains
688 JobStatus != 3 if the user wishes to avoid this condition.
689
691 The -format option provides a way to specify both the job attributes
692 and formatting of those attributes. There must be only one conversion
693 specification per -format option. As an example, to list only Jane
694 Doe's jobs in the queue, choosing to print and format only the owner of
695 the job, the command line arguments for the job, and the process ID of
696 the job:
697 $ condor_q -submitter jdoe -format "%s" Owner -format " %s " Args -format " ProcId = %d\n" ProcId
699 jdoe 16386 2800 ProcId = 0
700 jdoe 16386 3000 ProcId = 1
701 jdoe 16386 3200 ProcId = 2
702 jdoe 16386 3400 ProcId = 3
703 jdoe 16386 3600 ProcId = 4
704 jdoe 16386 4200 ProcId = 7
705 To display only the JobID's of Jane Doe's jobs you can use the follow‐
707 ing.
708 $ condor_q -submitter jdoe -format "%d." ClusterId -format "%d\n" ProcId
710 27.0
711 27.1
712 27.2
713 27.3
714 27.4
715 27.7
716 An example that shows the analysis in summary format:
718 $ condor_q -analyze:summary
720 -- Submitter: submit-1.chtc.wisc.edu : <192.168.100.43:9618?sock=11794_95bb_3> :
722 submit-1.chtc.wisc.edu
723 Analyzing matches for 5979 slots
724 Autocluster Matches Machine Running Serving
725 JobId Members/Idle Reqmnts Rejects Job Users Job Other User Avail Owner
726 ---------- ------------ -------- ------------ ---------- ---------- ----- -----
727 25764522.0 7/0 5910 820 7/10 5046 34 smith
728 25764682.0 9/0 2172 603 9/9 1531 29 smith
729 25765082.0 18/0 2172 603 18/9 1531 29 smith
730 25765900.0 1/0 2172 603 1/9 1531 29 smith
731 An example that shows summary information by machine:
733 $ condor_q -ana:sum,rev
735 -- Submitter: s-1.chtc.wisc.edu : <192.168.100.43:9618?sock=11794_95bb_3> : s-1.chtc.wisc.edu
737 Analyzing matches for 2885 jobs
738 Slot Slot's Req Job's Req Both
739 Name Type Matches Job Matches Slot Match %
740 ------------------------ ---- ------------ ------------ ----------
741 slot1@INFO.wisc.edu Stat 2729 0 0.00
742 slot2@INFO.wisc.edu Stat 2729 0 0.00
743 slot1@aci-001.chtc.wisc.edu Part 0 2793 0.00
744 slot1_1@a-001.chtc.wisc.edu Dyn 2644 2792 91.37
745 slot1_2@a-001.chtc.wisc.edu Dyn 2623 2601 85.10
746 slot1_3@a-001.chtc.wisc.edu Dyn 2644 2632 85.82
747 slot1_4@a-001.chtc.wisc.edu Dyn 2644 2792 91.37
748 slot1@a-002.chtc.wisc.edu Part 0 2633 0.00
749 slot1_10@a-002.chtc.wisc.edu Den 2623 2601 85.10
750 An example with two independent DAGs in the queue:
752 $ condor_q
754 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:35169?...
756 OWNER BATCH_NAME SUBMITTED DONE RUN IDLE TOTAL JOB_IDS
757 wenger DAG: 3696 2/12 11:55 _ 10 _ 10 3698.0 ... 3707.0
758 wenger DAG: 3697 2/12 11:55 1 1 1 10 3709.0 ... 3710.0
759 14 jobs; 0 completed, 0 removed, 1 idle, 13 running, 0 held, 0 suspended
761 Note that the "13 running" in the last line is two more than the total
763 of the RUN column, because the two condor_dagman jobs themselves are
764 counted in the last line but not the RUN column.
765 Also note that the "completed" value in the last line does not corre‐
767 spond to the total of the DONE column, because the "completed" value in
768 the last line only counts jobs that are completed but still in the
769 queue, whereas the DONE column counts jobs that are no longer in the
770 queue.
771 Here's an example with a held job, illustrating the addition of the
773 HOLD column to the output:
774 $ condor_q
776 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
778 OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
779 wenger CMD: /bin/slee 9/13 16:25 _ 3 _ 1 4 599.0 ...
780 4 jobs; 0 completed, 0 removed, 0 idle, 3 running, 1 held, 0 suspended
782 Here are some examples with a nested-DAG workflow in the queue, which
784 is one of the most complicated cases. The workflow consists of a
785 top-level DAG with nodes NodeA and NodeB, each with two two-proc clus‐
786 ters; and a sub-DAG SubZ with nodes NodeSA and NodeSB, each with two
787 two-proc clusters.
788 First of all, non-batch mode with all of the node jobs in the queue:
790 $ condor_q -nobatch
792 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
794 ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
795 591.0 wenger 9/13 16:05 0+00:00:13 R 0 2.4 condor_dagman -p 0
796 592.0 wenger 9/13 16:05 0+00:00:07 R 0 0.0 sleep 60
797 592.1 wenger 9/13 16:05 0+00:00:07 R 0 0.0 sleep 300
798 593.0 wenger 9/13 16:05 0+00:00:07 R 0 0.0 sleep 60
799 593.1 wenger 9/13 16:05 0+00:00:07 R 0 0.0 sleep 300
800 594.0 wenger 9/13 16:05 0+00:00:07 R 0 2.4 condor_dagman -p 0
801 595.0 wenger 9/13 16:05 0+00:00:01 R 0 0.0 sleep 60
802 595.1 wenger 9/13 16:05 0+00:00:01 R 0 0.0 sleep 300
803 596.0 wenger 9/13 16:05 0+00:00:01 R 0 0.0 sleep 60
804 596.1 wenger 9/13 16:05 0+00:00:01 R 0 0.0 sleep 300
805 10 jobs; 0 completed, 0 removed, 0 idle, 10 running, 0 held, 0 suspended
807 Now non-batch mode with the -dag option (unfortunately, condor_q
809 doesn't do a good job of grouping procs in the same cluster together):
810 $ condor_q -nobatch -dag
812 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
814 ID OWNER/NODENAME SUBMITTED RUN_TIME ST PRI SIZE CMD
815 591.0 wenger 9/13 16:05 0+00:00:27 R 0 2.4 condor_dagman -
816 592.0 |-NodeA 9/13 16:05 0+00:00:21 R 0 0.0 sleep 60
817 593.0 |-NodeB 9/13 16:05 0+00:00:21 R 0 0.0 sleep 60
818 594.0 |-SubZ 9/13 16:05 0+00:00:21 R 0 2.4 condor_dagman -
819 595.0 |-NodeSA 9/13 16:05 0+00:00:15 R 0 0.0 sleep 60
820 596.0 |-NodeSB 9/13 16:05 0+00:00:15 R 0 0.0 sleep 60
821 592.1 |-NodeA 9/13 16:05 0+00:00:21 R 0 0.0 sleep 300
822 593.1 |-NodeB 9/13 16:05 0+00:00:21 R 0 0.0 sleep 300
823 595.1 |-NodeSA 9/13 16:05 0+00:00:15 R 0 0.0 sleep 300
824 596.1 |-NodeSB 9/13 16:05 0+00:00:15 R 0 0.0 sleep 300
825 10 jobs; 0 completed, 0 removed, 0 idle, 10 running, 0 held, 0 suspended
827 Now, finally, the non-batch (default) mode:
829 $ condor_q
831 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
833 OWNER BATCH_NAME SUBMITTED DONE RUN IDLE TOTAL JOB_IDS
834 wenger ex1.dag+591 9/13 16:05 _ 8 _ 5 592.0 ... 596.1
835 10 jobs; 0 completed, 0 removed, 0 idle, 10 running, 0 held, 0 suspended
837 There are several things about this output that may be slightly confus‐
839 ing:
840 • The TOTAL column is less than the RUN column. This is because, for
842 DAG node jobs, their contribution to the TOTAL column is the number
843 of clusters, not the number of procs (but their contribution to the
844 RUN column is the number of procs). So the four DAG nodes (8 procs)
845 contribute 4, and the sub-DAG contributes 1, to the TOTAL column.
846 (But, somewhat confusingly, the sub-DAG job is not counted in the RUN
847 column.)
848 • The sum of the RUN and IDLE columns (8) is less than the 10 jobs
850 listed in the totals line at the bottom. This is because the
851 top-level DAG and sub-DAG jobs are not counted in the RUN column, but
852 they are counted in the totals line.
853 Now here is non-batch mode after proc 0 of each node job has finished:
855 $ condor_q -nobatch
857 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
859 ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
860 591.0 wenger 9/13 16:05 0+00:01:19 R 0 2.4 condor_dagman -p 0
861 592.1 wenger 9/13 16:05 0+00:01:13 R 0 0.0 sleep 300
862 593.1 wenger 9/13 16:05 0+00:01:13 R 0 0.0 sleep 300
863 594.0 wenger 9/13 16:05 0+00:01:13 R 0 2.4 condor_dagman -p 0
864 595.1 wenger 9/13 16:05 0+00:01:07 R 0 0.0 sleep 300
865 596.1 wenger 9/13 16:05 0+00:01:07 R 0 0.0 sleep 300
866 6 jobs; 0 completed, 0 removed, 0 idle, 6 running, 0 held, 0 suspended
868 The same state also with the -dag option:
870 $ condor_q -nobatch -dag
872 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
874 ID OWNER/NODENAME SUBMITTED RUN_TIME ST PRI SIZE CMD
875 591.0 wenger 9/13 16:05 0+00:01:30 R 0 2.4 condor_dagman -
876 592.1 |-NodeA 9/13 16:05 0+00:01:24 R 0 0.0 sleep 300
877 593.1 |-NodeB 9/13 16:05 0+00:01:24 R 0 0.0 sleep 300
878 594.0 |-SubZ 9/13 16:05 0+00:01:24 R 0 2.4 condor_dagman -
879 595.1 |-NodeSA 9/13 16:05 0+00:01:18 R 0 0.0 sleep 300
880 596.1 |-NodeSB 9/13 16:05 0+00:01:18 R 0 0.0 sleep 300
881 6 jobs; 0 completed, 0 removed, 0 idle, 6 running, 0 held, 0 suspended
883 And, finally, that state in batch (default) mode:
885 $ condor_q
887 -- Schedd: wenger@manta.cs.wisc.edu : <128.105.14.228:9619?...
889 OWNER BATCH_NAME SUBMITTED DONE RUN IDLE TOTAL JOB_IDS
890 wenger ex1.dag+591 9/13 16:05 _ 4 _ 5 592.1 ... 596.1
891 6 jobs; 0 completed, 0 removed, 0 idle, 6 running, 0 held, 0 suspended
893
895 condor_q will exit with a status value of 0 (zero) upon success, and it
896 will exit with the value 1 (one) upon failure.
897
899 HTCondor Team
900
902 1990-2022, Center for High Throughput Computing, Computer Sciences De‐
903 partment, University of Wisconsin-Madison, Madison, WI, US. Licensed
904 under the Apache License, Version 2.0.
9058.8 Jun 13, 2022 CONDOR_Q(1)