| msg48455 - (view) |
Author: Miki Tebeka (tebeka) * |
Date: 2005-06-14 09:11 |
| This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. |
|
|
| msg48456 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2005-07-11 16:30 |
| Logged In: YES user_id=21627 Converted to unified diff. |
|
|
| msg48457 - (view) |
Author: Karl Pietrzak (kap4020) |
Date: 2006-07-06 01:44 |
| Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. |
|
|
| msg48458 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2006-07-06 04:54 |
| Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. |
|
|
| msg48459 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2006-07-06 05:05 |
| Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. |
|
|
| msg48460 - (view) |
Author: Miki Tebeka (tebeka) * |
Date: 2006-07-09 14:07 |
| Logged In: YES user_id=358087 IIRC (the patch was done a long time ago), Python uses the process handle as the process id, I've tested the code and it worked. I agree that the patch need more work, mainly the error return value. At least on Python 2.4.3, TerminateProcess is not exposed by _subprocss (or subprocess). I still think that having a way to kill a process OOTB on win32 is very important, pretty swamped right now but I'll try to improve the patch. |
|
|
| msg48461 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2006-07-09 17:45 |
| Logged In: YES user_id=21627 "Python uses the process handle as process id" makes no real sense - Win32 works differently. You can't terminate a process without a handle, and you can't just "use" the process id as the handle. Perhaps some use cases for the API would need to be defined first. |
|
|
| msg48462 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2006-07-09 19:21 |
| Logged In: YES user_id=31435 Martin, FYI, on Windows the os.spawn() functions return the process handle, so that's the natural use case: killing a process spawned by Python's os.spawn*(). This is a little confusing because the spawn() functions are documented as returning "the process ID", and verbiage inside the spawn docs explains that it doesn't really mean "process ID" on Windows. |
|
|
| msg48463 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2006-07-09 21:30 |
| Logged In: YES user_id=21627 Ah, ok. Given that _subprocess already offers that functionality, I'm still -1 on adding it to "nt". Adding some kind of OpenProcess might be more useful, but then, people can get to all these functions through ctypes, as well. |
|
|
| msg48464 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2006-07-09 22:02 |
| Logged In: YES user_id=31435 Well, os.waitpid() on Windows also takes a process handle. This was (of course) deliberate, so that os.waitpid() could use the thingie returned by os.spawn() on Windows. If os.kill() were ever added to Windows, I think it would be quite natural for it to take a process handle too, and for the same reason (Python code mixing os.{spawn,waitpid,kill} could be the same across platforms). Zope's ZODB relies on mixing spawn and waitpid this way, and Zope's ZRS implements its own kill function on Windows so that the rest of the Python code can just do kill(id) on all platforms (where `id` is always something obtained from os.spawn()). |
|
|
| msg59787 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-01-12 04:54 |
| This should be implemented differently. Users should substitute their popen and exec calls with subprocess. The subprocess.Popen class should gain two new methods terminate() and send_signal(int) where send_signal is restricted to SIGKILL (+SIGTERM ?) on Windows. The idea was discussed on the Python dev list early last year. |
|
|
| msg59800 - (view) |
Author: Miki Tebeka (tebeka) * |
Date: 2008-01-12 05:21 |
| > Users should substitute their popen and exec calls with subprocess As long as popen and exec are available, users are free to use them (and probably will :) The Popen(...).terminate() works only if I'm the one who started the process. However there are cases where I want to kill all running python processes. The pids to be killed will come from somewhere else (ps, plist, ...). |
|
|
| msg62468 - (view) |
Author: Technologov (Technologov) |
Date: 2008-02-16 21:11 |
| Yes, this feature would be very important for me too... Anybody knows, _when_ it will be integrated into Python ? If this bugzilla supports email notifications, Please add me as "CC" for this bug. -Technologov |
|
|
| msg101774 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-03-27 00:22 |
| It would be really useful to be able to send signal.SIGINT to processes on Windows using os.kill(...). The patch as described sounds like it would have a different signature to the standard implementation of os.kill(...) which takes a pid and a signal type. IronPython 2.7 will have an os.kill implementation. Looks like it only supports signal.SIGINT and signal.SIGBREAK and just calls: Process toKill = Process.GetProcessById(pid); toKill.Kill() |
|
|
| msg101775 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-03-27 00:27 |
| I'm wrong. First IronPython tries: NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...) But with the comment: //The following calls to GenerateConsoleCtrlEvent will fail under //most circumstances. We'll try them any ways though as this seems //to be the only mechanism in Windows to send signals to processes It falls back to just killing the process. |
|
|
| msg101777 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-03-27 00:30 |
| Aaaand the IronPython implementation of NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...) delegates to Kernel32.GenerateConsoleCtrlEvent. |
|
|
| msg101828 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-03-27 13:52 |
| To make it clear, even though it would be incomplete, a partial implementation of os.kill(...) for Windows would be very useful and provide some level of compatibility with applications that use os.kill (so even if os.kill(...) duplicates functionality in other modules - although that was disputed - it should be provided for compatibility reasons). An implementation similar to the IronPython one is probably the best that can be managed and would still be useful: accepting only signal.SIGINT and signal.SIGBREAK and first trying Kernel32.GenerateConsoleCtrlEvent, falling back to killing the process. |
|
|
| msg101846 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-03-27 22:09 |
| So, Michael, what do you think: should os.kill expect a process handle, or a process ID? |
|
|
| msg101847 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-03-27 22:18 |
| Hmm... well my particular use case is that it should work with the value returned by os.getpid(). If that is a process handle then it is nice and convenient to just use process handles. The docs don't specify so I bet it returns a pid. :-( However Brian Curtin might want to weigh in on this as he has been looking at implementing this and there might be constraints. |
|
|
| msg101851 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-03-28 01:52 |
| I have this working with process IDs and my vote would be to keep it that way, as it would stay in-line with the other platforms, and it seems to work so far. I would imagine that was also IronPython's goal. I'm still working on the test portion of the patch. It should be ready shortly. |
|
|
| msg101970 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-03-31 02:10 |
| Here is a patch with some tests and doc changes. I'm having trouble coming up with tests which will work with CTRL_C_EVENT and CTRL_BREAK_EVENT. Based on my understanding of GenerateConsoleCtrlEvent, I figured this example (http://msdn.microsoft.com/en-us/library/ms685049%28v=VS.85%29.aspx) would be receptive to CTRL+C when started as a subprocess, but it doesn't work. I also figured "python -c "input()"" started as a subprocess could be killed with CTRL_C_EVENT, but it doesn't work either. |
|
|
| msg101973 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-03-31 02:50 |
| Removed an unnecessary goto and fixed a few tab/space inconsistencies (ugh). |
|
|
| msg102184 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-04-02 17:26 |
| After discussion with Brian it seems like it should be possible for os.kill(...) on Windows to support both pids *and* process handles. This seems ideal. |
|
|
| msg102200 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-02 21:01 |
| Michael, do you have an example of something which returns a handle? This current patch doesn't work with handles, but it wouldn't be hard to add it. I could make it work with the _handle object of a Popen object, but you could just as easily call os.kill on the pid of the Popen object. I don't know of any Python-wide handle object...I know subprocess has it's own, and don't really know what other functions are returning handles. Anyways, this patch includes an additional test script which uses ctypes to setup a console control handler, and CTRL_BREAK_EVENT is tested successfully. However, CTRL_C_EVENT is not. See http://msdn.microsoft.com/en-us/library/ms686016%28v=VS.85%29.aspx for details, but I'm not able to get the subprocess to work with CTRL+C. Calling SetConsoleCtrlHandler(NULL, FALSE) either in the script, test_os, or in _subprocess.c does not change anything, although it seems that it should. The CTRL_C_EVENT test is currently skipped in the patch until I can figure that out. |
|
|
| msg102202 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-04-02 21:05 |
| According to earlier discussion in this issue os.spawn() return process handles on Windows. |
|
|
| msg102213 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-02 23:27 |
| Committed to trunk in r79633 after talking with Michael about it. I'll forward port it after the 2.7 beta goes out. |
|
|
| msg102375 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-05 15:06 |
| FAQ should be updated http://www.python.org/doc/faq/windows/#how-do-i-emulate-os-kill-in-windows |
|
|
| msg102379 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-05 15:38 |
| How about something like this patch? |
|
|
| msg102385 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-05 17:15 |
| Seems good to me, even though I'd rewrite some parts like this: - Prior to Python 2.7 and 3.2, to terminate a process, you can use ctypes:: + Prior to Python 2.7 and 3.2, you can use linksomehow:`ctypes` to terminate a process:: ... In newer Python versions :func:`os.kill` works on Windows with the additional feature of being able to send CTRL+C and CTRL+BREAK to console subprocesses that understand these signals. ... -- anatoly t. On Mon, Apr 5, 2010 at 6:38 PM, Brian Curtin <report@bugs.python.org> wrote: > > Brian Curtin <curtin@acm.org> added the comment: > > How about something like this patch? > > ---------- > Added file: http://bugs.python.org/file16765/faq_update.diff > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue1220212> > _______________________________________ > |
|
|
| msg102965 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-12 18:11 |
| Ported to py3k in r80008. FAQ text updated in r80009 and r80010. |
|
|