The other commands hanging were because I had set the MaxSessions parameter artificially low for a previous test case. Those channels got failed at SSH2_MSG_CHANNEL_OPEN. That's one more mystery gone from the world. - Tim. On 2/6/14 2:22 PM, "Tim Broberg" <Tim.Broberg@xxxxxxxxxxxxxx> wrote: >Right now, the machine I'm experimenting against is running OpenSSH 5.5. > >I'm sending SSH2_MSG_CHANNEL_EOF right after I send the exec request, >because I have nothing further to say. > >SSH2_MSG_CHANNEL_CLOSE gets sent at the time that the timeout condition is >detected. > >I would expect the server to clean up and reply with >SSH2_MSG_CHANNEL_CLOSE, but the process remains open and I never do get a >SSH2_MSG_CHANNEL_CLOSE reply. > >When I eventually tear the whole session down, the process gets wiped out >then. > > - Tim. > >On 2/6/14 2:12 PM, "Damien Miller" <djm@xxxxxxxxxxx> wrote: > >>On Thu, 6 Feb 2014, Tim Broberg wrote: >> >>> Is anyone aware of a method to force termination of a single channel >>> without waiting for the associated process to complete? >> >>I think SSH2_MSG_CHANNEL_EOF then SSH2_MSG_CHANNEL_CLOSE might do what >>you want. >> >>> - SSH2_MSG_CHANNEL_CLOSE results in a long polling loop where sshd >>>keeps >>> trying to garbage collect the channel, but can't because the process is >>> still alive. Furthermore, this appears to be stalling the other >>>commands >>> as well. (More experimentation is needed on this point.) >> >>The server shouldn't hang while processing a close. >> >>> - I could try a SSH_MSG_CHANNEL_REQUEST "signal" and send SIGINT, >>> SIGTERM, SIGABRT, etc, but I don't see a handler for "signal" in the >>> server loop. >> >>No we don't support sending signals. There are patches on >>https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.mindrot.org/s >>h >>ow_bug.cgi?id%3D1424&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVYS%2Bpq3 >>4 >>MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=lwQZAeTp8nvxoDCauob1wrKWF%2FBMGa >>8 >>GWy6P15rmk04%3D%0A&s=0cac9f89eacfc4ea8547a46a88fe6027f645bbf485232537dc7a >>3 >>7ec3e36d760 but we're worried >>about possible problems of sshd signalling processes it shouldn't. >> >>-d >> > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev@xxxxxxxxxxx >https://urldefense.proofpoint.com/v1/url?u=https://lists.mindrot.org/mailm >an/listinfo/openssh-unix-dev&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVY >S%2Bpq34MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=HPhc5wDb28b5AiNdkNUHuRfZh >PFNMfVHrU7%2F%2FNrrbKY%3D%0A&s=8c78e166eae651ee088748ceb7104a258610d8cb8eb >0dfc9550d707b641e0a87 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev