Description of problem: If there is deferring job in in running state, but still waiting to deferral time, graceful stop doesn't move such job to idle state as it does for common running job. Version-Release number of selected component (if applicable): condor-7.6.1-0.10 How reproducible: 100% Steps to Reproduce: 1. submit job with deferral time i.e. # job.submit universe = vanilla cmd = /bin/sleep args = 20 deferral_time = (CurrentTime + 120) queue 1 $ condor_submit job.submit Submitting job(s). 1 job(s) submitted to cluster 1. 2. wait until job is matched with some slot $ condor_q -- Submitter: hostname : <IP:41815> : hostname ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 1.0 condor_user 6/8 17:04 0+00:00:32 R 0 2.0 sleep 1m 3. stop startd daemon, see job status # condor_off -subsystem startd Sent "Kill-Daemon" command for "startd" to local master $ condor_q -- Submitter: hostname : <IP:41815> : hostname ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 1.0 condor_user 6/8 17:04 0+00:01:32 R 0 2.0 sleep 1m Actual results: job still looks like running and it takes about 20 minutes till it change the state to idle, like the startd was killed by force Expected results: job status will be changed to idle after startd stop gracefully Additional info: for reproducing startd can be restarted too in that case the job still looks like running, but the job doesn't start on deferral time
state tracking upstream @: https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2486
The fix is notify the shadow that the job has exited, and should be rescheduled (107).
*** Bug 711993 has been marked as a duplicate of this bug. ***
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: C: Graceful stop of a startd where deferred jobs had landed but not yet run. C: Jobs would appear running in the schedd even though there was no starter running. F: Force starter to send job exit notification for deferred jobs R: Jobs will be rescheduled and transition to idle
Reproduced on RHEL 5.7 x86_64 with version condor-7.6.3-0.3. Verification on RHEL 5.7 i386: $ rpm -qa | grep condor condor-7.6.4-0.7.el5 condor-classads-7.6.4-0.7.el5 # cat /tmp/bz712026.job universe = vanilla cmd = /bin/sleep args = 20 deferral_time = (CurrentTime + 120) queue 1 # runuser -s /bin/bash -l condor -c "condor_submit /tmp/bz712026.job" Submitting job(s). 1 job(s) submitted to cluster 1. # condor_q -- Submitter: hostname : <IP:54068> : hostname ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 1.0 condor 10/12 14:34 0+00:00:02 R 0 0.0 sleep 20 1 jobs; 0 idle, 1 running, 0 held # condor_off -subsystem startd Sent "Kill-Daemon" command for "startd" to local master #condor_q -- Submitter: hostname : <IP:54068> : hostname ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 1.0 condor 10/12 14:34 0+00:00:08 I 0 0.0 sleep 20 1 jobs; 1 idle, 0 running, 0 held Output on other platforms (RHEL 5.7 x86_64, RHEL 6.1 i386, RHEL 6.1 x86_64) is similar. >>> VERIFIED
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -C: Graceful stop of a startd where deferred jobs had landed but not yet run. +When the startd daemon was gracefully stopped with some deferred jobs landed but not yet run, the jobs appeared to be running in the schedd daemon even though no starter was in operation. This update forces the starter to send job exit notification for deferred jobs and the jobs are now properly rescheduled and transition to the idle state, thus fixing this bug.-C: Jobs would appear running in the schedd even though there was no starter running. -F: Force starter to send job exit notification for deferred jobs -R: Jobs will be rescheduled and transition to idle
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0045.html