[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: https://github.com/python/cpython/pull/4283 adds a secondary timeout, which defaults to 1 s when there is no main timeout. But this seems complicated and arbitrary. As I understand, the main use case discussed here was waiting without a timeout for a child tha

[issue25942] subprocess.call SIGKILLs too liberally

Change by Gregory P. Smith : -- versions: +Python 3.7 -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue25942] subprocess.call SIGKILLs too liberally

Change by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mail

[issue25942] subprocess.call SIGKILLs too liberally

Change by Stuart Berg : -- pull_requests: +4245 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue25942] subprocess.call SIGKILLs too liberally

Mike Pomraning added the comment: Re: #2, I'd rather have a zombie than a hard kill on a child whose code I perhaps don't control. Zombies are a fact of life (er, a fact of undeath?) in UNIX process management, and are the historical and IMHO expected behavior. -- ___

[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: I don’t think Victor likes #2 because of the zombie. I would be interested in #4 (one of the documented purposes of subprocess is to replace os.system), but it might need careful consideration and discussion. Ignoring signals is such a significant change I thin

[issue25942] subprocess.call SIGKILLs too liberally

Mike Pomraning added the comment: #2 and #4 are the only predictable and palatable options, I think. Ignore the patch that started this issue. -- ___ Python tracker ___ ___

[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: When no timeout is specified, these are the options as I see them: 1. SIGKILL child immediately on the first KeyboardInterrupt (Victor’s behaviour since 3.3) 2. Give up and leave a zombie after the first KeyboardInterrupt (pre-3.3 behaviour) 3. Wait again aft

[issue25942] subprocess.call SIGKILLs too liberally

Mike Pomraning added the comment: Yes, standard UNIX terminal behavior is to map Ctrl-C to a SIGINT sent to the foreground process group, so that every member of a pipeline (e.g.) or hidden helper children processes can be terminated by the interactive user and have the chance to clean up. Ha

[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: I don’t know how it works on Windows, but on Unix in most cases the parent and child will share a controlling terminal. Pressing Ctrl+C in the terminal will broadcast SIGINT to all processes, parent and child. That is probably why os.system() ignores SIGINT. I

[issue25942] subprocess.call SIGKILLs too liberally

STINNER Victor added the comment: Again, the problem is that the exception exits from the function which owns the last reference to the Popen object. If the Popen is left alive when you exit the function, you create a zombi process, you can leave open pipes, etc. It's unclear to me if CTRL+c s

[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: Even if we can’t agree on any behaviour change, I think it might be worth documenting how these functions behave on exceptions (interrupts) other than TimeoutExpired. Currently all I can find is “If the timeout expires, the child process will be killed and wait

[issue25942] subprocess.call SIGKILLs too liberally

Changes by Robert Cope : -- nosy: +rpcope1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: The reported problem is when no timeout is given. Perhaps it would be sufficient to: 1. Kill the child if any exception happens when a timeout is enforced 2. Never kill the child when there is no timeout If a timeout is specified, the current code is good enoug

[issue25942] subprocess.call SIGKILLs too liberally

STINNER Victor added the comment: The issue explained in 12494 is that the caller doesn't have access to the subprocess.Popen object. I disagree to not kill the process when an exception is raised, even KeyboardInterrupt. I also disagree to say that we kill an "arbitrary" process. IMHO it's part

[issue25942] subprocess.call SIGKILLs too liberally

Martin Panter added the comment: Doesn’t this scenario apply equally to run(), or check_output() in 3.4? I suspect the explicit p.wait() call is not needed either. The context manager should already be calling wait(). One possible problem that I can think of: if you set a timeout, then interru

[issue25942] subprocess.call SIGKILLs too liberally

Mike Pomraning added the comment: If I understand correctly, the _try_wait mechanics (or 3.5's syscall behavior) already handle EINTR the way we way: ignore it and try wait()ing again. So, this patch would kill only on a timeout, and never on another error like Ctrl-C, a UserDefinedTimeoutExc

[issue25942] subprocess.call SIGKILLs too liberally

SilentGhost added the comment: The code was introduced to solve issue 12494, so I'm adding Victor to weigh in. -- nosy: +SilentGhost, haypo versions: +Python 3.5, Python 3.6 -Python 3.3 ___ Python tracker _

[issue25942] subprocess.call SIGKILLs too liberally

New submission from Mike Pomraning: Python 3.3 introduces timeout support in subprocess.call, implemented by sending a SIGKILL if the Popen.wait is interrupted by a TimeoutExpired exception. However, the "except" clause is too broad, and will, for instance, trigger on a KeyboardInterrupt. Fo