Compare this with the script in #14252:

p = Popen(['/bin/sleep', '1'])
time.sleep(1)
p.terminate()
print p.poll()
p.terminate()

Output is:

0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate
    self.send_signal(signal.SIGTERM)
  File "/usr/lib/python2.6/subprocess.py", line 1264, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process

The 0 return from poll() indicates that the subprocess ran to completion, rather than being terminated by the first terminate. So the first terminate does nothing, but the second terminate raises an exception. In http://bugs.python.org/issue14252#msg155396 :

"Raising an exception on terminate is a bug."

@Siona sorry about the delay in getting back to you.  Can someone try this please as I've only got Windows.

issue14252 appears to have been a fix for the windows side only.

On Posix the best that could be done here is to catch OSError within Popen.terminate() and Popen.kill() and ignore the problem if there was an error.

We do not have a way to know if the child process exists any longer or even to know if the process with the PID this call is sending the signal to is this Popen instances' child process or if the PID has already been recycled by the OS and used by another unfortunate process.

the bigger question is... should we.  this seems like an API change rather than a bugfix so I'm more inclined to do this in 2.5 only in case someone was relying on the exception to tell them that the process had already died.

For Posix (dunno about Windows), calling terminate or kill at the OS level after a poll or wait has already succeeded is a bad idea, because the PID may have been recycled. It is essentially operating on a released resource, similar to calling “os.close” on a closed FD, or freeing unallocated memory.

There is a way to know if the PID is still valid though. Just make sure that successful poll and wait calls invalidate the PID. Then calling terminate or kill, or any other operation that requires the PID, would no longer be valid (or could do nothing if that is more appropriate). Similar to the behaviour of file objects after they are closed: subsequent close calls do nothing; other operations raise an exception.

agreed, we could at least do that for the Popen methods.

This is more or less a dupe of Issue 6973, which also has a potential patch.