# \-c Paramiko hangs if stdout is large? **URL:** \ **Category:** Ansible Project\ **Created:** [January 28, 2013, 10:46pm UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259 "2013-01-28T22:46:27Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![fdavis](https://avatars.discourse-cdn.com/v4/letter/f/a698b9/32.png) [@fdavis](https://forum.ansible.com/u/fdavis)\ **Post date:** [January 28, 2013, 10:46pm UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/1 "2013-01-28T22:46:27Z")
Hello all, I don’t know if this is a paramiko problem, or our connection implementation for it, but the SSH connection seems to handle this okay. From running a ‘command: yum update -y’ for CentOS 5 machines on the recent upgrade, paramiko would sometimes hang indefinitely. Checking running processes and logs on the remote host would show that the yum update completed successfully. I believe the problem is having a large stdout returned. (I tested on localhost dumping big randomly generated string into a file and just catting from a playbook.) SSH spits out a buffered amount at a time, while paramiko just hangs. (no load on either local or remote host, no disk io happening, the process is just sitting around) Another case that may be related is an EC2 playbook for setting up cloud9. I believe the error started showing up after I switched back to paramiko from Fireball. The first sourcemint install (which dumps a whole lot to stdout) tends to fail. The error message claims mismatching quotes, but the install was successful. I thought I should bring this up in case anyone runs into similar behaviour. I remember something similar before in the mailing list, but I couldn’t find it. I think it was related to filesizes and paramiko?? PS: My cloud 9 playbook can be found here. [https://github.com/fdavis/ansible-ec2-env/tree/master/c9-servers/c9](https://github.com/fdavis/ansible-ec2-env/tree/master/c9-servers/c9) ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [January 28, 2013, 11:33pm UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/2 "2013-01-28T23:33:41Z")
We have a large output test for this reason, but tests are currently running -c local (they were not always). How large was large? ---
**Author:** ![Daniel\_Hokka\_Zakriss](https://avatars.discourse-cdn.com/v4/letter/d/f05b48/32.png) [@Daniel\_Hokka\_Zakriss](https://forum.ansible.com/u/Daniel_Hokka_Zakriss)\ **Post date:** [January 28, 2013, 11:40pm UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/3 "2013-01-28T23:40:59Z")
fdavis wrote: > Hello all, > > I don't know if this is a paramiko problem, or our connection > implementation for it, but the SSH connection seems to handle this okay. > > > > From running a 'command: yum update -y' for CentOS 5 machines on the > > recent upgrade, paramiko would sometimes hang indefinitely. > Checking running processes and logs on the remote host would show that the > yum update completed successfully. > > I believe the problem is having a large stdout returned. > (I tested on localhost dumping big randomly generated string into a file > and just catting from a playbook.) > > SSH spits out a buffered amount at a time, while paramiko just hangs. > (no load on either local or remote host, no disk io happening, the process > is just sitting around) > > Another case that may be related is an EC2 playbook for setting up cloud9. > I believe the error started showing up after I switched back to paramiko > from Fireball. > The first sourcemint install (which dumps a whole lot to stdout) tends to > fail. > The error message claims mismatching quotes, but the install was > successful. > > I thought I should bring this up in case anyone runs into similar > behaviour. > > I remember something similar before in the mailing list, but I couldn't > find it. > I think it was related to filesizes and paramiko?? This should be fixed on devel. Please test it again and see if it's still an issue. Daniel ---
**Author:** ![Daniel\_Hokka\_Zakriss](https://avatars.discourse-cdn.com/v4/letter/d/f05b48/32.png) [@Daniel\_Hokka\_Zakriss](https://forum.ansible.com/u/Daniel_Hokka_Zakriss)\ **Post date:** [January 28, 2013, 11:41pm UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/4 "2013-01-28T23:41:36Z")
Michael DeHaan wrote: > We have a large output test for this reason, but tests are currently > running -c local (they were not always). Yeah, running this test with -c paramiko triggered the issue. Daniel ---
**Author:** ![fdavis](https://avatars.discourse-cdn.com/v4/letter/f/a698b9/32.png) [@fdavis](https://forum.ansible.com/u/fdavis)\ **Post date:** [January 29, 2013, 12:38am UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/5 "2013-01-29T00:38:27Z")
My test file for the cat playbook was 100k. I estimated yum’s output to be about that order of magnitude, but didn’t get any real metrics on that. (stdout size: 80 char lines \* 400 pkgs \* 4 iterations (install, download, verify, cleanup on each package) ~= 128k) At any rate, it is fixed. So thank you 🙂 ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [January 29, 2013, 2:28am UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/6 "2013-01-29T02:28:14Z")
Seems reasonable to make the tests take the connection string from an environment variable, like TEST\_CONNECTION=\ or similar? The reason we did local was so you didn't need SSH setup for one, but also when making quick changes you could execute the test battery faster. ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [February 18, 2013, 4:43pm UTC](https://forum.ansible.com/t/c-paramiko-hangs-if-stdout-is-large/12259/7 "2013-02-18T16:43:59Z")
This is great to hear. In retrospect, this probably explains hangs we have seen from time to time, but given the fact there was no output we did not relate this to the amount of output.