condor_rm(1) [debian 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)
Check Out this Related Man Page
condor_checkpoint(1) General Commands Manual condor_checkpoint(1) Name condor_checkpoint send - a checkpoint command to jobs running on specified hosts Synopsis condor_checkpoint [-help -version] condor_checkpoint[-debug] [-pool centralmanagerhostname[:portnumber]] [-name hostnamehostname-addr "<a.b.c.d:port>""<a.b.c.d:port>"-con- straint expression-all] Description condor_checkpoint sends a checkpoint command to a set of machines within a single pool. This causes the startd daemon on each of the speci- fied machines to take a checkpoint of any running job that is executing under the standard universe. The job is temporarily stopped, a checkpoint is taken, and then the job continues. If no machine is specified, then the command is sent to the machine that issued the con- dor_checkpoint command. The command sent is a periodic checkpoint. The job will take a checkpoint, but then the job will immediately continue running after the checkpoint is completed. condor_vacate, on the other hand, will result in the job exiting (vacating) after it produces a checkpoint. If the job being checkpointed is running under the standard universe, the job produces a checkpoint and then continues running on the same machine. If the job is running under another universe, or if there is currently no Condor job running on that host, then condor_check- pointhas no effect. There is generally no need for the user or administrator to explicitly run condor_checkpoint. Taking checkpoints of running Condor jobs is handled automatically following the policies stated in the configuration files. Options -help Display usage information -version Display version information -debug Causes debugging information to be sent to stderr , based on the value of the configuration variable TOOL_DEBUG -pool centralmanagerhostname[:portnumber] Specify a pool by giving the central manager's host name and an optional port number -name hostname Send the command to a machine identified by hostname hostname Send the command to a machine identified by hostname -addr <a.b.c.d:port> Send the command to a machine's master located at "<a.b.c.d:port>" <a.b.c.d:port> Send the command to a machine located at "<a.b.c.d:port>" -constraint expression Apply this command only to machines matching the given ClassAd expression -all Send the command to all machines in the pool Exit Status condor_checkpointwill exit with a status value of 0 (zero) upon success, and it will exit with the value 1 (one) upon failure. Examples To send a condor_checkpoint command to two named machines: % condor_checkpoint robin cardinal To send the condor_checkpointcommand to a machine within a pool of machines other than the local pool, use the -pooloption. The argument is the name of the central manager for the pool. Note that one or more machines within the pool must be specified as the targets for the com- mand. This command sends the command to a the single machine named cae17within the pool of machines that has condor.cae.wisc.eduas its cen- tral manager: % condor_checkpoint -pool condor.cae.wisc.edu -name cae17 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_checkpoint(1)