You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Lyor Goldstein (Jira)" <ji...@apache.org> on 2021/04/13 15:52:00 UTC
[jira] [Updated] (SSHD-1144) type=SSH_FXP_CLOSE processing
interrupted
[ https://issues.apache.org/jira/browse/SSHD-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lyor Goldstein updated SSHD-1144:
---------------------------------
Labels: user-confirmation-required user-response-required (was: )
> type=SSH_FXP_CLOSE processing interrupted
> -----------------------------------------
>
> Key: SSHD-1144
> URL: https://issues.apache.org/jira/browse/SSHD-1144
> Project: MINA SSHD
> Issue Type: Bug
> Reporter: Ivan Fiorentini
> Priority: Major
> Labels: user-confirmation-required, user-response-required
>
> Some sftp clients (e.g. lftp) after a file-get they disconnect from the server without wait for the close-file (type=SSH_FXP_CLOSE processing) response.
> Here is an example of the "lftp get" exchange flow:
> {code:java}
> ---- Running connect program (ssh -a -x -s -l user -p 22022 localhost sftp)
> ---> sending a packet, length=5, type=1(INIT), id=0
> <--- SPENG SFTP Server - Primeur
> user@localhost's password: XXXX
> <--- got a packet, length=576, type=2(VERSION), id=0
> ---- protocol version set to 6
> ---> sending a packet, length=10, type=16(REALPATH), id=1
> <--- got a packet, length=33, type=104(NAME), id=1
> ---- home set to /IVNQM1/LOCALE
> ---- path on wire is `/IVNQM1/LOCALE/index.html'
> ---> sending a packet, length=47, type=3(OPEN), id=2
> <--- got a packet, length=41, type=102(HANDLE), id=2
> ---- got file handle 6636636436393765363835616664643564333437396263386434386632303932 (32)
> ---> sending a packet, length=45, type=8(FSTAT), id=3
> <--- got a packet, length=64, type=105(ATTRS), id=3
> ---- file info: size=612, date=Mon Mar 15 10:50:08 2021
> ---> sending a packet, length=53, type=5(READ), id=4
> ---> sending a packet, length=53, type=5(READ), id=5
> <--- got a packet, length=621, type=103(DATA), id=4
> ---- data packet: pos=0, size=612
> ---> sending a packet, length=53, type=5(READ), id=6
> <--- got a packet, length=28, type=101(STATUS), id=5
> ---- status code=1(EOF), message=End of file
> ---- eof
> ---> sending a packet, length=41, type=4(CLOSE), id=7
> ---- Disconnecting{code}
> On the server side, *using apache sshd 2.6.0*, the close-file processing (type=SSH_FXP_CLOSE processing) is delegated to the service thread "sshd-SftpSubsystem-thread-x" but when the disconnect (SSH_MSG_DISCONNECT) is received a "Thread.interrupt()" is invoked on the service thread "sshd-SftpSubsystem-thread-x".
> The service thread "sshd-SftpSubsystem-thread-x" then could be interrupted at an unpredictable moment and this could cause a missed close of the file or leaving the close-file processing in an inconsistent state (for example some other resources not properly closed due to the "InterruptedException", etc.).
> It seems there is no way to avoid the interrupt of the service thread "sshd-SftpSubsystem-thread-x" and/or wait the termination of the "type=SSH_FXP_CLOSE processing".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org