Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kill the entire subtree when killing child process #143

Merged
merged 3 commits into from
Sep 22, 2014

Conversation

guidow
Copy link
Contributor

@guidow guidow commented Sep 15, 2014

On Windows, killing a process will by default not kill that process's
child processes as well. This can be a problem when we're trying to stop
an assignment.

@opalmer opalmer added the bug label Sep 16, 2014
@opalmer opalmer added this to the 0.8.0 milestone Sep 16, 2014
@opalmer
Copy link
Member

opalmer commented Sep 16, 2014

I've seen this behavior a couple of times on Windows, usually it's because the process group is not setup correctly or the process was spawned in such a way that breaks the connection between parent and child. I have not seen this behavior on Linux however though it could be possible for grandchild processes.

All that said, could you please make a couple of modifications? sendSignal should do the right thing by default on all platforms, but obviously it won't always do this unfortunately. I think we should give it a chance to work how it's supposed however before trying to handle it ourselves since in most cases it may work properly.

I'm thinking something like this:

@classmethod
def _signal_process(signal, parent, children):
    assert signal in ("KILL", "TERM")
    method = signal.lower()
    if signal == "TERM":
        method = "terminate"

    if parent.is_running():
        getattr(parent, method)()  # needs a try: except Exception block

    for child in children:
        getattr(parent, method)()  # needs a try: except Exception block

def kill(self):
    process = self.psutil_process
    children = process.children(recursive=True)
    self.process.signalProcess("KILL")
    reactor.callLater(2, self._signal_process, parent, children)  # '2' should be configurable

@guidow guidow force-pushed the kill_child_processes branch from 8978171 to 9b6817e Compare September 18, 2014 16:52
@guidow
Copy link
Contributor Author

guidow commented Sep 19, 2014

Is this better now?

This still has problems, namely the process killed this way will return a return code of zero, signalling successful execution. In my test case (with Maya), this is not that much of a problem, because we are already parsing the process's output to know when a frame was finished, but it's still weird.

The best solution would probably involve setting up a correct process group when running on Windows, but I have no idea how to do that...

On Windows, killing a process will by default not kill that process's
child processes as well. This can be a problem when we're trying to stop
an assignment.
This gives kill() and terminate() a chance to do the right thing.
@guidow guidow force-pushed the kill_child_processes branch from 9b6817e to 7cf75c9 Compare September 19, 2014 14:17
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.11%) when pulling 3d34763 on guidow:kill_child_processes into 749131a on pyfarm:jobtype_rework.

@opalmer
Copy link
Member

opalmer commented Sep 21, 2014

Yes thank you, merge when ready.

The best solution would probably involve setting up a correct process group when running on Windows, but I have no idea how to do that...

I've done this before using pywin32 so I'll be happy to add it. Opening up #147 to work on this at a later time since for now the solution you have here is probably enough in the short term.

guidow added a commit that referenced this pull request Sep 22, 2014
Kill the entire subtree when killing child process
@guidow guidow merged commit 40f1eef into pyfarm:jobtype_rework Sep 22, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants