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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
