[issue31712] subprocess with stderr=subprocess.STDOUT hang

l4mer added the comment: confirm, OpenSSH_7.3p1 solve the problem. Thanks for help. -- resolution: -> third party status: -> closed ___ Python tracker ___ ___

[issue31712] subprocess with stderr=subprocess.STDOUT hang

Martin Panter added the comment: Scanning over the Open SSH commits for 7.3p1 https://github.com/openssh/openssh-portable/compare/V_7_2_P2...V_7_3_P1 it looks like this commit https://github.com/openssh/openssh-portable/commit/d2d6bf864e52af8491a60dd507f85b74361f5da3 may fix your problem. It

[issue31712] subprocess with stderr=subprocess.STDOUT hang

l4mer added the comment: Interesting when using faster machine with newer ssh don't see this problem :) janusz@t560:~$ ssh -V OpenSSH_7.3p1 Ubuntu-1ubuntu0.1, OpenSSL 1.0.2g 1 Mar 2016 janusz@t560:~$ ssh root@localhost -O exit; strace python test.py getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, r

[issue31712] subprocess with stderr=subprocess.STDOUT hang

l4mer added the comment: I) Manual test for subprocess32: janusz@nc6120:~$ python Python 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess32 >>> cmd = ["ssh", "root@localhost", "-p

[issue31712] subprocess with stderr=subprocess.STDOUT hang

l4mer added the comment: janusz@nc6120:~$ ssh -V OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016 janusz@nc6120:~$ I) manual check janusz@nc6120:~$ ssh root@localhost -p 50494 -O exit janusz@nc6120:~$ python Python 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609] on lin

[issue31712] subprocess with stderr=subprocess.STDOUT hang

Gregory P. Smith added the comment: Please try to reproduce this with Python 3.6. On 2.7, I highly recommend you stop using the Python 2.7 subprocess module and install the subprocess32 backport available on PyPI. It is *much* more reliable. -- ___

[issue31712] subprocess with stderr=subprocess.STDOUT hang

Martin Panter added the comment: Presumuing your file descriptor 3 is the read end of the pipe to the child’s output, then there is probably a process somewhere that could still write to the write end. Normally “check_output” waits until it has read all possible output from the pipe(s). This

[issue31712] subprocess with stderr=subprocess.STDOUT hang

l4mer added the comment: BTW, when you will check point 3 you will notice that we already read id output, so command execute correctly: "uid=0(root" ... And problem is after that. Steps I reproduce this issue: - standard user have keys and in ~/.ssh/config Host * ControlMaster auto Cont

[issue31712] subprocess with stderr=subprocess.STDOUT hang

l4mer added the comment: yes, works perfectly when omit stderr=subprocess.STDOUT no matter if mux exists. Also from bash: ssh user@locahost id always works. Problem exists only when stderr=subprocess.STDOUT and no MUX yet. BTW, first connection create a MUX - but this seems to be an unimportant

[issue31712] subprocess with stderr=subprocess.STDOUT hang

R. David Murray added the comment: Given the title, are you saying that it works if you omit the stderr=subprocess.STDOUT? At the beginning you say you are using an authorized key and mux so you don't need to enter a password, and at the end you say it works fine if the MUX is created. So t

[issue31712] subprocess with stderr=subprocess.STDOUT hang

New submission from l4mer : I am using ssh mux + authorized key. So can exectute commands without passwod. 1. disconnect mux by: ssh user@localhost -O exit 2. run simple script import subprocess if __name__ == '__main__': cmd = ["ssh", "user@localhost", "id"] try: buf = subproce