I previously wrote:

> I suspect the problem may be on the "identify which process to kill"
> rather than the "kill it" part, but it's definitely going to take time
> to figure that out for sure.  While the approach kill_python takes is
> much more appropriate, since we don't currently have multiple builds
> running simultaneously (and for me the machines are dedicated as build
> slaves, so I won't be having my own python_d), a more blanket kill
> operation is safe enough.

For anyone interested, I caught (well, Georg Brandl caught it first) a
case on Saturday with some hung processes on the Win7 buildbot that I
was able to verify kill_python failed to kill.  This was after having
a few instances where it did work fine.

I've created issue 10641 to track.  I also noticed another recent
issue (10136) that is also related to kill_python missing processes,
but given that it works in my case some of the time, and is always
called via the same path, not sure if that can be my problem.

I also realized that some fraction of the other cases I have seen
might not have truly been an issue, since from what I can see
kill_python is only run at the start of a build process, so hung
processes (even killable ones) from a prior build hang around until
the next build takes place.  They can however, interfere with the svn
checkout so things never get to the point of using kill_python.  So
maybe kill_python's use should be moved to the clean stage?

-- David

Python-Dev mailing list

Reply via email to