2010-03-18 4 views
2

참고 :ssh_sftp 채널을 예제로 사용하겠습니다. 그러나 다른 채널을 사용할 때 동일한 동작을 발견했습니다. 얼랑 SSH 채널 중지 문제

채널을 시작한 후 : (cm 내 연결 관리자입니다)

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

, 내가 채널을 통해 작업을 수행하고있다. 말 :

ssh_sftp:write_file(ChannelPid, FilePath, Content), 

그럼, 채널 정지 해요 : 내가 아는 한, 채널은 gen_server로 구현됩니다

이후
ssh_sftp:stop_channel(ChannelPid), 

가, 내가 sequentialized 할 요청 기다리고 있었다.

글쎄, 약간의 추적 후에 채널이 어떻게 든 멈추는 것을 알았습니다 전에 전에 파일 쓰기가 완료되고 작업 결과가 채널을 통해 전송됩니다. 결론적으로, 채널은 더 이상 존재하지 않으므로 응답은 채널을 통해 전송되지 않습니다.

채널을 명시 적으로 중지하지 않으면 모든 것이 올바르게 작동하고 파일 쓰기 (또는 채널을 통해 수행 된 다른 작업)가 올바르게 완료됩니다. 그러나 열린 채널을 벗어나는 것을 피하는 것이 좋습니다. 반면에 채널을 멈추기 전에 결과를 기다리기 위해 자체 수신 핸들러를 구현하는 것을 피하는 것이 좋습니다.

아마도 여기에 사소한 것이 빠져있을 것입니다. 왜 이런 일이 일어 났는지 그리고/또는 해결할 수있는 아이디어가 있습니까?

반복하면 ssh_sftp은 그 예입니다. Erlang SSH 응용 프로그램의 기존 채널을 템플릿으로 사용하여 구현 한 자체 채널을 사용하고 있습니다.

+0

''ssh_sftp.erl'을 보았습니다 만, 파일이 제대로 쓰여질 때까지 write_file이 어떻게 대기 하는지를 볼 수 없습니다. 무작위 추측 : ssh_sftp : write_file의 반환 값을 확인하십시오. – legoscia

답변

1

당신이 강제로 출구와 5 초 타임 아웃 후 채널을 죽이고 ssh_sftp.erl에서 볼 수 있듯이 (PID를 죽이고)에 관계없이 일을 처리 여부를인지하는 과정을 중단.

erlang man에서

관련 인용 :

이유는 원자 죽일 인 경우 종료 (PID가, 죽일) 경우, 즉 호출 할 때, untrappable 종료 신호는 무조건 종료 이유와 출구가 살해되는도 (Pid)로 전송 .

1

나는 ssh_connection : exec/4와 비슷한 문제가있었습니다. 문제는 이러한 ssh 형제 모듈 (ssh_connection, ssh_sftp 등)이 모두 비동기 적으로 동작하는 것처럼 보이므로 ssh 채널의 종료로 인해 진행중인 작업이 종료됩니다.

옵션은 다음과 같습니다

1) 연결을 종료하지 않습니다이 자원의 누수가 발생할 수 있습니다. 내 질문의 목적 here

2) 원격 서버에서 전송중인 파일 (체크섬 검사)을 모니터링하여 대기하는 모니터링 기능을 도입하십시오. 이것은 ssh_connection을 기반으로 할 수 있습니다 : 전송중인 파일의 exec 및 poll.체크섬이 예상과 일치하면 주 모듈을 해제 할 수 있습니다.