Timing out a channel exec request

[Tim Broberg]

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 at servicenow.com> 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 at mindrot.org> 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 at mindrot.org
>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