-
Notifications
You must be signed in to change notification settings - Fork 599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to notify remote exec command of an EOF of the stdin #143
Comments
it's possible this got broken by d955865 |
So if I uncomment it back in my project, will there be any problem? |
Did this fix the issue? I ran into the same thing |
@tsingakbar @nstogner Could one of you verify that that fixes the problem, and write a unit test that shows this solves it? Then I'll readd the line. I don't know why it was removed, the commit message isn't really saying much... @shikhar Why was it removed? |
I was trying to further simplify teardown flow (as a follow-up to 5ee2f0a), and thought sending the EOF for stdout was redundant since in typical usage the channel would be closed soon after. This was probably a bad idea. |
I'm commenting the line out again, just ran into the following:
|
I just ran into this issue when needing to send data to stdin of ssh script. I had to commit a deadly sin to work around it: public static void writeEOF(OutputStream o) throws Exception {
if (!(o instanceof ChannelOutputStream)) return;
ChannelOutputStream out = (ChannelOutputStream) o;
Field f1 = ChannelOutputStream.class.getDeclaredField("trans");
f1.setAccessible(true);
Transport trans = (Transport) f1.get(out);
Field f2 = ChannelOutputStream.class.getDeclaredField("chan");
f2.setAccessible(true);
Channel chan = (Channel) f2.get(out);
trans.write(new SSHPacket(Message.CHANNEL_EOF).putUInt32(chan.getRecipient()));
} I am writing env via stdin as I ran into #128 Nice library otherwise :) |
Also got bitten by this. This is how I wrote a workaround, only using public methods:
Could we make this an option on the channel, so people have the option of controlling whether or not to send EOF? |
All IntelliJ-based IDEs use SSHJ by default since 2019.2 version, with a similar workaround on the IDE side that sends EOF-packets on close of every exec channel. (Recently the same behaviour has been added to tcpip-forwardings and shell channels, but it's not released yet. Let's have a look if there is still some doubt.) For year and a half we've received myriad of stacktraces and bug reports, but none of them have been related to this race. Even though I remember I managed to catch the mentioned "Received something for nonexistent channel" error once or twice while I was working on the new SSH backend for 2019.2. Instead of avoiding sending EOF packets, I'd consider changing reactions on receiving packets from unexpected channels. ConnectionImpl and ChannelInputStream can merely ignore wrong packets. I read the RFC 4254 section 5 and didn't find any obligation regarding handling packets from unexpected channel. And finally, if I'm not mistaken, both OpenSSH client and server ignore such packets. |
I've been trying to use SSHJ for Jepsen as well, and hit this issue too. It looks like I can work around it by following @asgeirn's approach, though I'm not sure if I'm setting myself up for race conditions as a result. It'd be great if there were some kind of official documentation for "how not to leave commands hanging forever"! :-) |
I'm trying to use sshj to implement something like
cat foo.tar.gz | ssh user@remote tar xzf -
, and I used theCommand.getOutputStream()
to feed these bytes from a local file named foo.tar.gz, but when all bytes is fed, I can't find a way to shutdown the process gracefully.Invoking the close() method on the stream won't work.
The text was updated successfully, but these errors were encountered: