Bug 589673 - condor_configd needs a graceful shutdown method on Windows
Summary: condor_configd needs a graceful shutdown method on Windows
Status: CLOSED DUPLICATE of bug 586561
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: condor
Version: Development
Hardware: All
OS: Windows
medium
medium
Target Milestone: 1.3
: ---
Assignee: Pete MacKinnon
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 559596
TreeView+ depends on / blocked
 
Reported: 2010-05-06 16:27 UTC by Pete MacKinnon
Modified: 2010-08-27 12:45 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-05-06 17:27:03 UTC


Attachments (Terms of Use)

Description Pete MacKinnon 2010-05-06 16:27:04 UTC
When the master shuts down a daemon on Windows it invokes the configured target of WINDOWS_SOFTKILL which by default is condor_softkill. This exe basically looks for the Windows handle associated with a PID passed to it using the Win32 C API. When it finds a match, it "posts" a message of WM_CLOSE to that handle which is generally considered the graceful way of shutting down a Window console. Of course this works fine for the C++ exes like startd, kbdd, etc. which have handlers for WM_CLOSE provided by daemon core. In the case of the Python interpreter, WM_CLOSE is meaningless to it and application-specific. Not sure how the signal lib is implemented but SIGTERM certainly doesn't appear to equal WM_CLOSE.

One way to do this would be to use the Python Extensions for Windows. They can be used to properly register a Windows-specific handler for the WM_CLOSE message. However this adds additional dependencies we could do without.

Recommend an approach of just having:
1) a softkill replacement that touches a pid kill file on the local dir somewhere, and
2) update the configd to scan for this file on a timer

Comment 1 Pete MacKinnon 2010-05-06 17:27:03 UTC

*** This bug has been marked as a duplicate of bug 586561 ***


Note You need to log in before you can comment on or make changes to this bug.