Replies: 6 comments
-
Hi there, Thanks for the interest. Reading partial output from commands that do not terminate is described in the documentation. Using the example as in the documentation, the behaviour is as expected:
The documentation describes how to close the remote command. No thread pools should be used - channels cannot be shared (safely) across threads with parallel-ssh. The duplicated output is because of the use of threads - there are multiple channels using the same socket across threads, both of them will have output. Can re-open if there is an issue with documented example as shown above. Use the high level APIs in clients for writing to stdin, not OS pipes. They will not work. |
Beta Was this translation helpful? Give feedback.
-
What's wrong with my use of pipes? I'm not actually passing a pipe to parallel-ssh. I'm reading from the pipe and then writing with I don't think I can completely eliminate threads. That same library requires a thread. But that thread ( Finally, while I did see the stuff about |
Beta Was this translation helpful? Give feedback.
-
Sure, have a look at the poll command. If you're not passing data to/from an SSH channel with pipes, that's fine. Pipes are inherently blocking, so you can't use them for network communication of SSH traffic. Reading/writing from them inside a shell is fine, that's standard shell output. The problematic code, as far as I can see without minimal code to reproduce that can be run anywhere, is this block here:
channels cannot be used in a thread pool in this way. Things will break. Can call If a standalone piece of code that I can run locally can be shown I can take a look. Otherwise just guessing from looking at code. The other thing is you need Also these:
These are blocking calls. You need It sounds like a combination of a low |
Beta Was this translation helpful? Give feedback.
-
What's wrong with the example I posted above? Can you not run that locally? |
Beta Was this translation helpful? Give feedback.
-
Can tell it doesn't work from all the blocking calls - select, channel.write etc. Once those are changed, does it work? The issue tracker is for actionable bugs, not instructions how to use. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Background
I'm trying to execute a long-running command on a remote server. It needs to be fed data through stdin, and it may occasionally print stuff through stdout and stderr. It will not terminate until it gets EOF on its input. I have a working program that uses Paramiko. It multiplexes over the SSH channel and another file descriptor with
select
, and reads from both sources in non-blocking mode. However, my attempt at using parallel-ssh exhibits a few bugs.Describe the bug
for line in channel.stdout
?channel.stdout
. How can I do that in a nonblocking way?select
always returns that the channel is readable, butexit_code
is alwaysNone
so the program busy loops. Why doesn'texit_code
get set?To Reproduce
Execute this program like this:
python3.9 cat-parallelssh.py my-host
. To see problem 3, change therange
arguments to0, 10
.Expected behavior
It should print the numbers 0 through 999, inclusive, each on its own line and then terminate. For comparison, this paramiko program does just that:
Actual behaviour
It typically prints the numbers 0 through 21 twice and then hangs. The exact numbers printed varies from run to run.
Additional information
ssh2_python-0.27.0
Beta Was this translation helpful? Give feedback.
All reactions