You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a question regarding the exitcode for single-command SSH connections.
I am currently using the following piece of code (in Kotlin - abbreviated to focus on the main points)
importcom.jcraft.jsch.ChannelExecimportcom.jcraft.jsch.JSchimportjava.io.BufferedReaderimportjava.io.InputStreamReaderimportcom.jcraft.jsch.SessionfuncreateSession(): Session {
returnJSch().getSession("127.0.0.1")
}
funrun(command:String) {
val channel = createSession().openChannel("exec") asChannelExectry {
channel.setCommand(command)
val reader =BufferedReader(InputStreamReader(channel.inputStream))
channel.connect()
var lastLine =""while (reader.readLine()?.also { lastLine = it } !=null) {
doStuff(lastLine)
}
} finally {
channel.disconnect()
while (!channel.isClosed) {
Thread.sleep(10)
}
if (channel.exitStatus !=0) {
throwException("something went wrong")
}
}
}
Rarely this fails on commands that I'd expect to run successfully (as the stdout output is correct, in these cases the exitStatus is -1) - I expect some kind of race condition. After checking the code, it looks like isClosed is set before the ChannelClose package is sent, whose response sets the exitStatus.
Is there a way to correctly read the exitStatus after the Channel is closed? AFAIK -1 is a valid exitStatus, which is why I cannot wait until this value changes (and it opens other issues with busy waiting)
If not, please consider this a feature request.
The text was updated successfully, but these errors were encountered:
Hey!
I have a question regarding the exitcode for single-command SSH connections.
I am currently using the following piece of code (in Kotlin - abbreviated to focus on the main points)
Rarely this fails on commands that I'd expect to run successfully (as the stdout output is correct, in these cases the exitStatus is -1) - I expect some kind of race condition. After checking the code, it looks like isClosed is set before the ChannelClose package is sent, whose response sets the exitStatus.
Is there a way to correctly read the exitStatus after the Channel is closed? AFAIK -1 is a valid exitStatus, which is why I cannot wait until this value changes (and it opens other issues with busy waiting)
If not, please consider this a feature request.
The text was updated successfully, but these errors were encountered: