X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Date: Fri, 12 Nov 2010 16:19:55 +1300 Message-ID: Subject: Python: subprocess running rsync causes broken socket in telnetlib From: David Antliff To: cygwin Content-Type: multipart/mixed; boundary=001485eafcbe8c04100494d29093 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --001485eafcbe8c04100494d29093 Content-Type: text/plain; charset=ISO-8859-1 I'm reporting a problem I see on Cygwin because I do not see the same behaviour on Ubuntu Linux - both systems are running Python 2.6.5. I have a script that opens a long-term telnet connection (telnetlib) to a remote host. There is an object called Telnet().socket that is created and represents an active socket connection to the remote host, once the right telnetlib calls are made. Then the script uses subprocess to do something else (the line is actually longer than this but I've simplified it to the most basic version that exhibits the problem): process = subprocess.Popen("rsync", stdout=subprocess.PIPE) On Cygwin 1.7.7, this does something nasty to the completely unrelated yet existing telnetlib socket so that any further attempts to read or write from this socket raise an exception: File "/usr/lib/python2.6/telnetlib.py", line 280, in write self.sock.sendall(buffer) File "", line 1, in sendall socket.error: [Errno 32] Broken pipe On Linux, this doesn't happen at all. I've tried a few other programs via subprocess like "cat" and "ssh" but they don't seem to cause this problem - only "rsync" does so far. There may be others but I haven't found them. If anyone is prepared to look into this I have attached a small python script (bug.py) that demonstrates the problem. The error returned in this case is "113: Software caused connection abort", but the end result is the same - the socket is broken by the call to subprocess & rsync: $ python bug.py ('telnet', '220 mx.google.com ESMTP w42sm3212723wfh.15\r\n') ('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n') ('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n') ('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996') Traceback (most recent call last): File "bug.py", line 38, in print("telnet", t.read_eager()) File "/usr/lib/python2.6/telnetlib.py", line 370, in read_eager self.fill_rawq() File "/usr/lib/python2.6/telnetlib.py", line 516, in fill_rawq buf = self.sock.recv(50) socket.error: [Errno 113] Software caused connection abort If you edit the script and set 'crash' to False, you'll see that the script completes without error: $ python bug.py ('telnet', '220 mx.google.com ESMTP i16sm3108013ibl.0\r\n') ('ssh', 0, 'OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010\n') ('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n') ('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250') And on Linux: $ python bug.py ('telnet', '220 mx.google.com ESMTP i16sm3106343ibl.18\r\n') ('ssh', 0, 'OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009\n') ('telnet', '250-mx.google.com at your service, [202.27.34.1]\r\n') ('rsync', 0, 'rsync version 3.0.7 protocol version 30\nCopyright (C) 1996') ('telnet', '250-SIZE 35651584\r\n250-8BITMIME\r\n250-STARTTLS\r\n250') rsync is version 3.0.7. -- David. --001485eafcbe8c04100494d29093 Content-Type: text/x-python; charset=US-ASCII; name="bug.py" Content-Disposition: attachment; filename="bug.py" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggehvqjd0 IyEvdXNyL2Jpbi9weXRob24KIiIiClNjcmlwdCB0byBkZW1vbnN0cmF0ZSBo b3cgY29tYmluYXRpb24gb2Ygc3VicHJvY2VzcyAmIHJzeW5jIGNhdXNlcyBh IHRlbG5ldGxpYiBjb25uZWN0aW9uIHRvIGZhaWwuCkRhdmlkIEFudGxpZmYs IE5vdiAyMDEwCiIiIgppbXBvcnQgdGVsbmV0bGliCmltcG9ydCBzdWJwcm9j ZXNzCmltcG9ydCB0aW1lCgojICoqKioqKioqIGNoYW5nZSB0aGlzIHRvIEZh bHNlIHRvIGF2b2lkIHRoZSBjcmFzaApjcmFzaCA9IFRydWUKCiMgVXNlIEdv b2dsZSdzIFNNVFAgc2VydmVyIGFzIGEgZGVtb25zdHJhdGlvbgpob3N0ID0g InNtdHAuZ21haWwuY29tIgpwb3J0ID0gMjUKCiMgY29ubmVjdCB0byBhIHJl bW90ZSBob3N0IHdpdGggdGVsbmV0bGliCnQgPSB0ZWxuZXRsaWIuVGVsbmV0 KCkKdC5vcGVuKGhvc3QsIHBvcnQpCnRpbWUuc2xlZXAoMSkKcHJpbnQoInRl bG5ldCIsIHQucmVhZF9lYWdlcigpKQoKIyBUSEUgRk9MTE9XSU5HIExJTkUg RE9FUyBOT1QgU0VFTSBUTyBDQVVTRSBBIFBST0JMRU0KcHJvY2VzcyA9IHN1 YnByb2Nlc3MuUG9wZW4oWyJzc2giLCAiLVYiXSwgc3Rkb3V0PXN1YnByb2Nl c3MuUElQRSwgc3RkZXJyPXN1YnByb2Nlc3MuU1RET1VUKQpvdXRwdXQgPSBw cm9jZXNzLmNvbW11bmljYXRlKClbMF0KcmV0Y29kZSA9IHByb2Nlc3MucmV0 dXJuY29kZQpwcmludCgic3NoIiwgcmV0Y29kZSwgb3V0cHV0KQoKIyBxdWVy eSB0aGUgdGVsbmV0IHNlcnZlcgp0LndyaXRlKCJFSExPXHJcbiIpCnRpbWUu c2xlZXAoMSkKcHJpbnQoInRlbG5ldCIsIHQucmVhZF9lYWdlcigpKQoKaWYg Y3Jhc2g6CiAgICAjIFRIRSBGT0xMT1dJTkcgTElORSBLSUxMUyBUSEUgdGVs bmV0bGliIFNPQ0tFVAogICAgcHJvY2VzcyA9IHN1YnByb2Nlc3MuUG9wZW4o WyJyc3luYyIsICItLXZlcnNpb24iXSwgc3Rkb3V0PXN1YnByb2Nlc3MuUElQ RSkKICAgIG91dHB1dCA9IHByb2Nlc3MuY29tbXVuaWNhdGUoKVswXQogICAg cmV0Y29kZSA9IHByb2Nlc3MucmV0dXJuY29kZQogICAgcHJpbnQoInJzeW5j IiwgcmV0Y29kZSwgb3V0cHV0WzA6NjBdKQoKIyB0aGlzIHdpbGwgbm93IHJl c3VsdCBpbiBhIGNyYXNoIGJlY2F1c2UgdGhlIGNvbm5lY3Rpb24gaXMgbG9z dDoKcHJpbnQoInRlbG5ldCIsIHQucmVhZF9lYWdlcigpKQp0LndyaXRlKCJR VUlUXHJcbiIpCnQuY2xvc2UoKQoK --001485eafcbe8c04100494d29093 Content-Type: text/plain; charset=us-ascii -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple --001485eafcbe8c04100494d29093--