> Who says close should not be initiated by client to immediately
> terminate the channel & process?
Nobody. It was a thought. As you mentioned: "it is outside specifications".
> It's however not guaranteed it's possible to send a kill signal after the CLOSE so
> waiting like that puts the client in a little odd situation if the program never exits.
That why i think it would be better to send signal before closing the
channel. The handling
depends on situation. I believe in most cases people just run commands
like "mkdir" of "ifconfig"
which work pretty fast so not close nor signal is necessary. In case
like mine the sequence should
be signal -> wait_for_close if you want to force stop process. This is
what happens when you press
Ctrl+C or stop service by TERM signal. Normal way. I start thinking
that closing channel for stop purposes
is a bit brutal :) Only in case of INT/TERM/... signals program can
handle it and stop gracefully. I hope you
understand what i mean, usually i don't write so much in English, heh.
I'd like to hear your opinion. Should something be changed or not in
libssh2 based on my investigation?
> EOF should differ significantly as it's unidirectional. Sending EOF
> should only close stdin to the program, stdout should still be connected
> to the channel.
Yes, i think you're right. I'm out of mind a bit after research :) I
had to review all openssh server code, libssh2 code and so on.
I'm really newbie in all this SSH internals.
2011/10/14 Henrik Nordström <henrik_at_henriknordstrom.net>:
> fre 2011-10-14 klockan 16:00 -0700 skrev Pavel Strashkin:
>> OK, after really long investigation i've found the reason why it
>> hangs. Now i'm not sure either client or server is the reason of that.
>> The following stuff is happening. When "close" is received by server,
>> it closes pipes (stdout, ...) connected to the program and waits for
>> program termination. When pipe closed from one side, other side will
>> get SIGPIPE signal when attempting to write, but...before each write
>> it waits for [interval] seconds so that's why it hangs for the same
>> time. I'm talking about iostat, mpstat. I think it should be
>> documented very clearly in libssh2 docs for further users. The same
>> happens for "eof" request.
>
> Who says close should not be initiated by client to immediately
> terminate the channel & process?
>
> Sure, it's not the normal way, but there is nothing wrong with it.
>
> How the server shuts down the running program when receiving a CLOSE
> request is outside specifications, but I would not expect it to wait for
> the program to exit before responding to the CLOSE requests. But
> implementations are free to wait if they insist. It's however not
> guaranteed it's possible to send a kill signal after the CLOSE so
> waiting like that puts the client in a little odd situation if the
> program never exits.
>
> EOF should differ significantly as it's unidirectional. Sending EOF
> should only close stdin to the program, stdout should still be connected
> to the channel.
>
> Regards
> Henrik
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-10-15