condor_wait(1) [debian man page]
condor_wait(1) General Commands Manual condor_wait(1) Name condor_wait Wait - for jobs to finish Synopsis condor_wait [-help -version] condor_wait[-debug] [-wait seconds] [-num number-of-jobs] log-file[job ID] Description condor_waitwatches a user log file (created with the logcommand within a submit description file) and returns when one or more jobs from the log have completed or aborted. Because condor_waitexpects to find at least one job submitted event in the log file, at least one job must have been successfully submitted with condor_submitbefore condor_waitis executed. condor_waitwill wait forever for jobs to finish, unless a shorter wait time is specified. Options -help Display usage information -version Display version information -debug Show extra debugging information. -wait seconds Wait no more than the integer number of seconds. The default is unlimited time. -num number-of-jobs Wait for the integer number-of-jobsjobs to end. The default is all jobs in the log file. log file The name of the log file to watch for information about the job. job ID A specific job or set of jobs to watch. If the job IDis only the job ClassAd attribute ClusterId , then condor_wait waits for all jobs with the given ClusterId . If the job IDis a pair of the job ClassAd attributes, given by ClusterId . ProcId , then condor_wait waits for the specific job with this job ID. If this option is not specified, all jobs that exist in the log file when condor_wait is invoked will be watched. General Remarks condor_waitis an inexpensive way to test or wait for the completion of a job or a whole cluster, if you are trying to get a process outside of Condor to synchronize with a job or set of jobs. It can also be used to wait for the completion of a limited subset of jobs, via the -numoption. Examples condor_wait logfile This command waits for all jobs that exist in logfile to complete. condor_wait logfile 40 This command waits for all jobs that exist in logfile with a job ClassAd attribute ClusterId of 40 to complete. condor_wait -num 2 logfile This command waits for any two jobs that exist in logfile to complete. condor_wait logfile 40.1 This command waits for job 40.1 that exists in logfile to complete. condor_wait -wait 3600 logfile 40.1 This waits for job 40.1 to complete by watching logfile , but it will not wait more than one hour (3600 seconds). Exit Status condor_waitexits with 0 if and only if the specified job or jobs have completed or aborted. condor_waitreturns 1 if unrecoverable errors occur, such as a missing log file, if the job does not exist in the log file, or the user-specified waiting time has expired. Author Condor Team, University of Wisconsin-Madison Copyright Copyright (C) 1990-2012 Condor Team, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI. All Rights Reserved. Licensed under the Apache License, Version 2.0. See the Condor Version 7.8.2 Manualor http://www.condorproject.org/licensefor additional notices. condor-admin@cs.wisc.edu September 2012 condor_wait(1)
Check Out this Related Man Page
condor_rm(1) General Commands Manual condor_rm(1) Name condor_rm remove - jobs from the Condor queue Synopsis condor_rm [-help -version] condor_rm[-debug] [-forcex] [-pool centralmanagerhostname[:portnumber]-name scheddname][-addr "<a.b.c.d:port>"] cluster... clus- ter.process... user... -constraint expression... condor_rm[-debug] [-pool centralmanagerhostname[:portnumber]-name scheddname][-addr "<a.b.c.d:port>"] -all Description condor_rmremoves one or more jobs from the Condor job queue. If the -nameoption is specified, the named condor_scheddis targeted for pro- cessing. Otherwise, the local condor_scheddis targeted. The jobs to be removed are identified by one or more job identifiers, as described below. For any given job, only the owner of the job or one of the queue super users (defined by the QUEUE_SUPER_USERS macro) can remove the job. When removing a grid job, the job may remain in the ``X'' state for a very long time. This is normal, as Condor is attempting to communi- cate with the remote scheduling system, ensuring that the job has been properly cleaned up. If it takes too long, or in rare circumstances is never removed, the job may be forced to leave the job queue by using the -forcexoption. This forcibly removes jobs that are in the ``X'' state without attempting to finish any clean up at the remote scheduler. Options -help Display usage information -version Display version information -pool centralmanagerhostname[:portnumber] Specify a pool by giving the central manager's host name and an optional port number -name scheddname Send the command to a machine identified by scheddname -addr <a.b.c.d:port> Send the command to a machine located at "<a.b.c.d:port>" -debug Causes debugging information to be sent to stderr , based on the value of the configuration variable TOOL_DEBUG -forcex Force the immediate local removal of jobs in the 'X' state (only affects jobs already being removed) cluster Remove all jobs in the specified cluster cluster.process Remove the specific job in the cluster user Remove jobs belonging to specified user -constraint expression Remove all jobs which match the job ClassAd expression constraint -all Remove all the jobs in the queue General Remarks Use the -forcexargument with caution, as it will remove jobs from the local queue immediately, but can orphan parts of the job that are running remotely and have not yet been stopped or removed. Examples For a user to remove all their jobs that are not currently running: % condor_rm -constraint 'JobStatus =!= 2' Exit Status condor_rmwill exit with a status value of 0 (zero) upon success, and it will exit with the value 1 (one) upon failure. Author Condor Team, University of Wisconsin-Madison Copyright Copyright (C) 1990-2012 Condor Team, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI. All Rights Reserved. Licensed under the Apache License, Version 2.0. See the Condor Version 7.8.2 Manualor http://www.condorproject.org/licensefor additional notices. condor-admin@cs.wisc.edu September 2012 condor_rm(1)