Skip to content

Migration from LSF to HTCondor: commands

This page aims to provide a simple mapping between lsf and HTCondor commands.

Job Submission

In HTCondor bsub is replaced with condor_submit.

Sample usage and output:

$ condor_submit job.sub 
Submitting job(s).
1 job(s) submitted to cluster 845004.

For more information: Man page

Job removal

In HTCondor bkill is replaced with condor_rm.

Sample usage and output:

$ condor_rm <user>
All jobs of user <user> have been marked for removal

Note: you only have rights to remove your own jobs from the system.

For more information: Man page

Job Querying

In HTCondor bjobs is replaced with condor_q.

Sample usage and output:

$ condor_q


-- Schedd: bigbird02.cern.ch : <128.142.196.38:9618?... @ 12/18/17 14:40:34
OWNER    BATCH_NAME        SUBMITTED   DONE   RUN    IDLE  TOTAL JOB_IDS
<user> CMD: job.sh  12/18 14:40      _      _      1      1 845012.0

1 jobs; 0 completed, 0 removed, 1 idle, 0 running, 0 held, 0 suspended

Note: condor_q will query the schedd host that is currently assigned to the user. Moreover, this command offers a lot of useful options to the user. For more information please refer to the man page below:

Man page

Job History.

In HTCondor bhist is replaced with condor_history.

Sample usage and output:

$ condor_history <user> -limit 1
 ID     OWNER          SUBMITTED   RUN_TIME     ST COMPLETED   CMD            
845012.0   <user>       12/18 14:40              X         ???  /afs/cern.ch/... 845012 0

Please note: you should always use the -limit option to limit the amount of lines that will be returned, in order to avoid putting unncessary stress to the collector hosts.

For more information: Man page

Cluster and nodes information.

Although not providing the exact same information lsf commands like lsid and bhosts can be replaced with various forms of the condor_status command.

Sample usage and output:

$condor_status -any 
MyType             TargetType         Name                                                  

Machine            Job                slot1@b6a003b7cf.cern.ch                              
Machine            Job                slot1_1@b6a003b7cf.cern.ch                            
Machine            Job                slot1_2@b6a003b7cf.cern.ch                            
Machine            Job                slot1_3@b6a003b7cf.cern.ch                            
Machine            Job                slot1_6@b6a003b7cf.cern.ch                            
Machine            Job                slot1_7@b6a003b7cf.cern.ch                            
Machine            Job                slot1_8@b6a003b7cf.cern.ch                            
Machine            Job                slot1@b6a011e60d.cern.ch   

The command above shows all the machines, of various roles, that are present in the batch cluster.

$condor_status -collector
Name                                             Machine                                          RunningJobs IdleJobs HostsTotal

CERN Condor Share@tweetybird03.cern.ch           tweetybird03.cern.ch                                       0        0       8522
CERN Condor Share@tweetybird04.cern.ch           tweetybird04.cern.ch                                  104938    11662     119864

With the command above we can see the collector hosts in the cluster.

Generally, condor_status is a rather powerful command that, with its various options, can provide the user with a lot of interesting information.

For more information please refer to the man page below:

Man page

Examining stdout/stderr of a job on runtime.

In HTCondor bpeek is replaced with condor_tail or condor_ssh_to_job.

$ condor_tail -f -stderr -auto-retry 845443.0 
stdout
stderr

Man page

Man page

Queues

As mentioned in the previous sections (Migration concepts) the concept of a queue does not exist in HTCondor. Thus the commands bqueues, btop and bbot do not have equivalents.