开发者

Problem stopping an Erlang SSH channel

开发者 https://www.devze.com 2022-12-23 21:59 出处:网络
NOTE: I\'ll use the ssh_sftp channel as an example here, but I\'ve noticed th开发者_运维百科e same behaviour when using different channels.

NOTE: I'll use the ssh_sftp channel as an example here, but I've noticed th开发者_运维百科e same behaviour when using different channels.

After starting a channel:

{ok, ChannelPid} = ssh_sftp:start_channel(State#state.cm),

(where cm is my Connection Manager), I'm performing an operation through the channel. Say:

ssh_sftp:write_file(ChannelPid, FilePath, Content),

Then, I'm stopping the channel:

ssh_sftp:stop_channel(ChannelPid),

Since, as far as I know, the channel is implemented as a gen_server, I was expecting the requests to be sequentialized.

Well, after a bit of tracing, I've noticed that the channel is somehow stopped before the file write is completed and the result of the operation is sent through the channel. As a conclusion, the response is not sent through the channel, since the channel doesn't exist anymore.

If I don't stop the channel explicitely, everything works fine and the file write (or any other operation performed through the channel) is completed correctly. But I would prefer to avoid to leave open channels. On the other hand, I would prefer to avoid implementing my own receive handler to wait for the result before the channel can be stopped.

I'm probably missing something trivial here. Do you have any idea why this is happening and/or I could fix it?

I repeat, the ssh_sftp is just an example. I'm using my own channels, implemented using the existing channels in the Erlang SSH application as a template.


As you can see in ssh_sftp.erl it forcefully kills channel after 5 sec timeout with exit(Pid, kill) which interrupts the process regardless of whether it's processing something or not.

Related quote from erlang man:

If Reason is the atom kill, that is if exit(Pid, kill) is called, an untrappable exit signal is sent to Pid which will unconditionally exit with exit reason killed.


I had a similar issue with ssh_connection:exec/4. The problem is that these ssh sibling modules ( ssh_connection, ssh_sftp, etc) all appear to behave asynchronously, therefore a closure of channel of ssh itself will shut down the ongoing action.

The options are:

1) do not close the connection : this may lead to leak of resources. Purpose of my question here

2) After the sftp, introduce a monitoring function that waits by monitoring on the file you are transfering at the remote server ( checksum check ). This can be based on ssh_connection:exec and poll on the file you are transferring. Once the checksum matches what you expect, you can free the main module

0

精彩评论

暂无评论...
验证码 换一张
取 消