Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add closeImmediately param to Client.exec #57

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

skirsdeda
Copy link
Contributor

For using long running commands (say 'tail -f'), it is necessary to finish stdout stream whenever some expected results come and bind Process Resource usage to IO producing stream results. That way, resource is closed even though command is still running.
The problem lies in channel.close(false) which is run as part of closing the resource and takes 1 minute to complete (because command is still running and mina ssh client is just waiting for default 1min timeout). It should be possible to close channel immediately for such use case.
Since there is no way to cancel command, this seems to be the only option. And it works :)

@skirsdeda skirsdeda requested a review from djspiewak February 6, 2020 12:32
@djspiewak
Copy link
Contributor

djspiewak commented Feb 6, 2020

Hmm, wouldn't it be better instead to adjust the behavior of exec to more closely approximate this? https://stackoverflow.com/a/28812832/9815 As far as I know, closeImmediately doesn't actually kill off the remote command, it just disconnects the connection.

@skirsdeda
Copy link
Contributor Author

It doesn't kill off the command, but it disconnects the session sooner. The command is killed off by remote side as soon as the session dies. Could it be that usePty = true is the default behavior in this case?

@skirsdeda
Copy link
Contributor Author

skirsdeda commented Feb 6, 2020

The obvious difference I am seeing is that it doesn't hang for 1 minute after the stream completes when closeImmediately=true. Command is killed off in both cases though.

@skirsdeda
Copy link
Contributor Author

@djspiewak, added a test case to demonstrate this use case.
Tested with closeImmediately=false/true on several servers and on one (Ubuntu/WSL) there was no difference while on other (RHEL 7.7) I saw those long timeouts on channel close (when closeImmediately=false).
Also tried to call channel.setUsePty(true) after channel creation and it apparently breaks streaming somehow (test case fails with NoSuchElementException thrown from fs2).
And then I tried to see what's the difference of SSHD behavior between the two servers but couldn't find anything notable.

@skirsdeda
Copy link
Contributor Author

@djspiewak, any decision on this one? I am stuck using custom build of fs2-ssh just because of this.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants