Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 712026

Summary:	graceful stop of startd, doesn't move deferring jobs to idle state
Product:	Red Hat Enterprise MRG	Reporter:	Lubos Trilety <ltrilety>
Component:	condor	Assignee:	Timothy St. Clair <tstclair>
Status:	CLOSED ERRATA	QA Contact:	Daniel Horák <dahorak>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	dahorak, matt, mkudlej, tstclair
Target Milestone:	2.1
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	condor-7.6.4-0.5	Doc Type:	Bug Fix
Doc Text:	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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-23 17:27:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	711993, 743350

Description Lubos Trilety 2011-06-09 10:05:54 UTC

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

Comment 2 Timothy St. Clair 2011-09-21 17:18:09 UTC

state tracking upstream @: https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2486

Comment 3 Timothy St. Clair 2011-09-21 19:05:43 UTC

The fix is notify the shadow that the job has exited, and should be rescheduled (107).

Comment 4 Timothy St. Clair 2011-09-23 13:33:11 UTC

*** Bug 711993 has been marked as a duplicate of this bug. ***

Comment 5 Timothy St. Clair 2011-09-23 20:25:33 UTC

    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

Comment 11 Daniel Horák 2011-10-12 11:42:48 UTC

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

Comment 12 Tomas Capek 2011-11-17 12:56:56 UTC

    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

Comment 13 errata-xmlrpc 2012-01-23 17:27:08 UTC

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