I think that the script could do with some improvements - Use strict and warnings, three arg open with proper error checking, error checking on the close due to the piped open, and using <> instead of <STDIN> would be some best practices that would also make the script more robust and easily debuggable in case of errors.
Anyway, I think huck is on to something. I can reproduce the problem when I run the program as ./1194547.pl <hosts.txt, but when I run the program as cat hosts.txt | perl 1194547.pl, it works. Also, adding the </dev/null to the command as huck suggested makes it work as well, as does using the ssh -n switch, which has the same effect. So while I haven't dug into the details, changing the uptime to cat does seem to show that the problem is ssh is reading STDIN and sending it to the remote command.
However, as I wrote about at length here, shelling out to an external process is not always a good idea, especially when you can't trust the user input. The great Net::OpenSSH module, while it does also use external ssh processes, does this in a more robust fashion, plus it provides a whole lot more functionality (Net::OpenSSH::Parallel might be of interest to you). I would strongly recommend using that module instead of shelling out to ssh yourself.
In reply to Re: Odd perl/ssh interaction
by haukex
in thread Odd perl/ssh interaction
by mlf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |