Issue 6973: subprocess.Popen.send_signal doesn't check whether the process has terminated

When subprocess.Popen.send_signal is called, it simply calls
os.kill(self.pid, ...) without checking whether the child has already
terminated. If the child has been terminated, and Popen.wait() or
Popen.poll() have been called, a process with PID self.pid no longer
exists, and what's worse, could belong to a totally unrelated process.

A better behavior would be to raise an exception when self.returncode is
not None. Alternatively, self.pid might be set to None after the process
has been terminated, as it is no longer meaningful. Or to another value
that would be invalid pid and invalid argument to os.kill and os.wait,
but unlike None would still evaluate to True.

I agree with Milko. 

However, I think Popen.send_signal should poll() before sending any
signals, without resetting any variables to zero (or None).
In this way, if you poll() before sending a signal, if the return code
is None, the child is still running. If the poll return code is
different than None, the child has been terminated, so you must not send
anything to the child process.

In this way, instead of polling before sending signals to check if the
child has been terminated, we can make Python do the work for us.

I've provided a patch. All the tests pass.
A new test has been added: test_terminate_already_terminated_child.
This method asserts `terminate()` (through `send_signal`) raises an
OSError exception. 

However, even though you try the old version of subprocess.py all the
tests pass. This happens because the method `send_signal` calls
os.kill() (or Terminate for Windows systems) that can raise an OSError
exception if the process to which it send the signal does not exist. 
`send_signal` has been fixed to be a safer method, so that it raises an
OSError exception if the child has been terminated.

I totally agree this should be fixed (there was a similar issue for psutil: http://code.google.com/p/psutil/issues/detail?id=58) but communicate() and wait() should be affected in the same manner.

Probably it would make sense to add an is_running() method and decorate send_signal(), kill(), communicate() and wait() methods with a function which makes sure that the process is still running, otherwise raises an exception instead.

Maybe it would also makes sense to provide a brand new NoSuchProcess exception class.

It seems to me that raising OSError isn’t quite right. Either the error is more of an internal programmer error, like how writing to a closed file object raises ValueError, or there should not be an error, like when the process has terminated but has not been reaped, or when closing an already-closed file.

New changeset 6bd3c8623bb2 by Gregory P. Smith in branch '3.4':
Fix issue #6973: When we know a subprocess.Popen process has died, do
https://hg.python.org/cpython/rev/6bd3c8623bb2

New changeset bc907c76f054 by Gregory P. Smith in branch '3.5':
Fix issue #6973: When we know a subprocess.Popen process has died, do
https://hg.python.org/cpython/rev/bc907c76f054

New changeset e51c46d12ec1 by Gregory P. Smith in branch 'default':
Fix issue #6973: When we know a subprocess.Popen process has died, do
https://hg.python.org/cpython/rev/e51c46d12ec1

I chose to go with the "there should not be an error" approach similar to how Python deals with multiple file closes.  Both are technically programming errors but the point of Python is make life easier.

Reasoning?  I don't want someone to ever think they could depend on getting an exception from send_signal/terminate/kill in this "process has already died and someone has called wait or poll to get its return code" situation as that is unreliable and potentially impacts other innocent processes.

nosy: + gregory.p.smith

versions: - Python 3.2

nosy: + markon
messages: + msg94091

keywords: + patch

stage: needs patch