classification
Title: os.kill on windows
Type: enhancement Stage: committed/rejected
Components: Interpreter Core Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brian.curtin Nosy List: Technologov, andersjm, brian.curtin, christian.heimes, dino.viehland, kap4020, loewis, michael.foord, nnorwitz, tebeka, techtonik, tim.peters, trent
Priority: normal Keywords: patch

Created on 2005-06-14 09:11 by tebeka, last changed 2010-04-12 18:11 by brian.curtin. This issue is now closed.

Files
File name Uploaded Description Edit
diff.zip tebeka, 2005-06-14 09:11 Zip of source and documentation
kill.diff loewis, 2005-07-11 16:30
issue1220212.patch brian.curtin, 2010-04-02 21:01
faq_update.diff brian.curtin, 2010-04-05 15:38
Messages (30)
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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2010-04-12 18:11
Ported to py3k in r80008.

FAQ text updated in r80009 and r80010.
History
Date User Action Args
2010-04-12 18:11:07brian.curtinsetstatus: open -> closed
resolution: fixed
messages: + msg102965
2010-04-05 17:15:56techtoniksetmessages: + msg102385
2010-04-05 15:38:27brian.curtinsetfiles: + faq_update.diff

messages: + msg102379
2010-04-05 15:06:59techtoniksetnosy: + techtonik
messages: + msg102375
2010-04-02 23:27:47brian.curtinsetassignee: brian.curtin
type: enhancement
messages: + msg102213
stage: committed/rejected
2010-04-02 21:05:31michael.foordsetmessages: + msg102202
2010-04-02 21:01:26brian.curtinsetfiles: + issue1220212.patch
nosy: + dino.viehland
messages: + msg102200

2010-04-02 20:48:44brian.curtinsetfiles: - issue1220212.patch
2010-04-02 17:26:31michael.foordsetmessages: + msg102184
2010-03-31 02:50:22brian.curtinsetfiles: + issue1220212.patch

messages: + msg101973
2010-03-31 02:41:31brian.curtinsetfiles: - issue1220212.patch
2010-03-31 02:10:25brian.curtinsetfiles: + issue1220212.patch

messages: + msg101970
2010-03-28 01:52:52brian.curtinsetmessages: + msg101851
2010-03-27 22:18:31michael.foordsetmessages: + msg101847
2010-03-27 22:09:55loewissetmessages: + msg101846
2010-03-27 13:58:43michael.foordsetnosy: + brian.curtin
2010-03-27 13:52:37michael.foordsetmessages: - msg101829
2010-03-27 13:52:17michael.foordsetmessages: + msg101829
2010-03-27 13:52:12michael.foordsetmessages: + msg101828
2010-03-27 00:30:56michael.foordsetmessages: + msg101777
2010-03-27 00:27:54michael.foordsetmessages: + msg101775
2010-03-27 00:22:55michael.foordsetversions: + Python 2.7, Python 3.2, - Python 2.6
2010-03-27 00:22:21michael.foordsetnosy: + michael.foord
messages: + msg101774
2008-08-25 12:23:26andersjmsetnosy: + andersjm
2008-04-08 14:06:11trentsetnosy: + trent
2008-02-16 21:11:29Technologovsetnosy: + Technologov
messages: + msg62468
2008-01-12 05:21:54tebekasetmessages: + msg59800
2008-01-12 04:54:33christian.heimessetnosy: + christian.heimes
messages: + msg59787
versions: + Python 2.6, - Python 2.5
2005-06-14 09:11:53tebekacreate