in reply to Re^6: Threads Printing Issue - Output Mangled / Term Crashing
in thread Threads Printing Issue - Output Mangled / Term Crashing

It is not "putting something in a variable" that changed your local prompt, i.e. not something that ssh sent to its output, but something that ssh did to its (and per the -t Option: your) terminal

... just like changing the time (e.g. via `date -s ...`) affects the whole System, regardless of whether you assign that command's output to a variable or print it directly (or discard it completely)

In programming this is called a side effect, although it is often the main reason for doing it :-)

Replies are listed 'Best First'.
Re^8: Threads Printing Issue - Output Mangled / Term Crashing
by bigbot (Beadle) on Apr 15, 2014 at 06:25 UTC
    Yeah that's true. I was looking at it the wrong way. I think I have a pretty good idea of what the issue is with this new information, thanks.
      strace may show something interesting. For instance:
      strace -o /tmp/out -f perl -e 'print `ssh localhost -tt -l root tcpdum +p -c10 -nntttt`'

      On my computer that works pretty fine, and I don't see any tty access. Maybe just updating the ssh client could solve your problem.

      update: Ah, I can see what's happening:

      ssh -tt ... reads the terminal flags from STDIN (ioctl(0, TCGETS, ...)), sets new ones (ioctl(0, TCSETSW,, ...)) and runs the remote command. Then, upon exit, it restores the original flags.

      The issue is that with multiple ssh processes running in parallel, some of them may read the already modified flags and so later, reset STDIN to an incorrect state.

      An easy workaround is to wrap the part of the code where the threads are started and then joined with an extra couple of TCGETS/TCSETSW ioctl calls. Another option is to just redirect STDIN from /dev/null.

      update 2: The following program works correctly on my computer:

      use strict; use warnings; use threads; use threads::shared; my @threads; my @servers = (('localhost') x 100); my $lock:shared; foreach my $server (@servers) { chomp $server; push (@threads, threads->create (\&dumpServer, $server)); } foreach (@threads) { $_->join(); } sub dumpServer { my $server = shift; my $net = `ssh -l root -tt $server '/usr/sbin/tcpdump -c10 -nntttt 2 +>&1' </dev/null`; lock($lock); print "TEST - $server\n$net\n\n"; }
        Thank you, awesome find! This will save me from doing another 8 hours of troubleshooting. :)

        Well, your solution worked :) At least as far as fixing the term issue. However, a side effect is that the processes continue running on the servers after the SSH connection is killed (arrrrgh). So sorta back to square one.

        I have had some luck with the following line, but it feels like a cheesy way (and not 100%) to fix the issue. Before the print and in various places:

        system('stty sane');

        So confirmed that it's definitely a term settings issue. Over 95% of the time there are no print issues. However, now trying to pipe the output into any other tool crashes the program (leaving tons of threads running and dormant processes). Other users will certainly pipe the output so that's a problem. Maybe I need to pass Perl code to the servers like you were saying (to kill the processes once SSH is killed). This way I don't need to use that buggy -tt SSH option.