[Condor-users] Job runs forever if transfer_output_files = ON_EXIT

[Oren Livne <livne@xxxxxxxxxxxx>]

Dear All,

I am submitting a job to Condor to a Linux AMD 64-bit cluster (I do not 
have admin privileges there). If I don't transfer the output directory 
(chr22) back, the job runs and completes successfully, although chr22 is 
created within the job's spool directory as it should.

If I add the transfer_output_files = chr22 property, the job runs forever:

 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
  76.0   livne           9/26 14:50   0+00:01:43 R  0 0.0  split_chr.sh 
split

1 jobs; 0 idle, 1 running, 0 held

Local output directory -- no chr22, no out and no err
total 20
-rw-r--r-- 1 livne brdfuser 1166 Sep 26 13:38 split_chr.sub
-rwxr-xr-x 1 livne brdfuser  152 Sep 26 14:17 split_chr.sh
-rw-r--r-- 1 livne brdfuser    0 Sep 26 14:18 split_chr.out
-rw-r--r-- 1 livne brdfuser    0 Sep 26 14:18 split_chr.err
-rw-r--r-- 1 livne brdfuser 9113 Sep 26 14:19 split_chr.log

Submitted this file with condor_submit:
universe                       = vanilla
output                         = split_chr.out
error                          = split_chr.err
log                            = split_chr.log
should_transfer_files          = YES
initialdir                     = out/split_chr
executable                     = out/split_chr/split_chr.sh
arguments                      = split.py -c $(chr) 
/clusta/livne/data/hutt/hutt 50 -o chr$(chr)/hutt
notification                   = Never
environment                    = 
PYTHONPATH=/clusta/livne/ober/util:/clusta/livne/ober/impute:/clusta/livne/ober/network:/clusta/livne/ober/famplot
transfer_input_files           = 
/clusta/livne/ober/impute/impute/batch/split.py, 
/clusta/livne/data/hutt/hutt.bed, /clusta/livne/data/hutt/hutt.bim, 
/clusta/livne/data/hutt/hutt.fam, /clusta/livne/data/hutt/hutt.pdg.tfam
transfer_output_files          = chr$(chr)
when_to_transfer_output        = ON_EXIT

queue

This runs fine on my local Linux machine with 4 procs and Condor 7.8.4.

Thank you,
Oren