C에서 부정한 소켓 클로저를 디버깅하는 방법은 무엇입니까?

Question

TIME_WAIT 상태에서 클라이언트마다 하나씩 소켓 파일 설명자가 누설되는 네트워크 데몬 (poll()/accept()/fork() 스타일)이 있습니다.

필자가 볼 수있는 한, 나는 더 이상 필요없는 소켓을 종료하고 닫을 수 있습니다. 다른 소켓 (예 : 포크의 클라이언트 측에있는 서버 소켓)은 바로 닫힙니다. 모든 소켓은 SO_REUSEADDR을 설정하고 SO_LINGER는 해제합니다. _exit()을 사용하여 프로그램을 종료하고 비 블로킹 폴링 소켓 작업을 사용하여 신호 처리기에서 '죽어가는'플래그를 설정합니다. 이렇게하면 나중에 죽어가는 플래그를 가져 와서 무료로 사용할 수 있습니다.), shutdown(), close() (시그널 핸들러에서는 위험 할 수있다).

하지만 여전히 fd가 누출되었습니다. 이런 종류의 문제를 디버깅하는 가장 좋은 방법은 무엇입니까? 프로세스에 관련된 많은 fds가 있기 때문에 종료 할 때 어떤 소켓이 느슨한 지 알면 도움이됩니다.

건배!

Answer 1

소켓 누출되지 않습니다 - TIME_WAIT는 응용 프로그램이 소켓을 완료하고 그것을 폐쇄하고 그것을 정리했지만, 제대로 응답 할 수 있도록 커널은 여전히 ​​소켓을 기억된다는 것을 의미한다 늦은/고아/중복 패킷 네트워크에 떠 다니는 수도 있습니다. 잠시 후, 커널은 자동으로 TIME_WAIT 소켓을 삭제할 것이다. 그러나 그때까지는 SO_REUSEADDR로 앱이 특별히 요구하지 않는 한, 포트를 재사용하지 말 것을 커널에 알리는 역할을한다.

Answer 2

나는 이것을 알아 냈다.

Infact 나는 포크의 서버 쪽에서 cli_fd를 닫음으로써 이미 버그를 수정했다. 그러나 내가 버그를 고쳤다는 것을 알지 못했습니다. 왜냐하면 내가 natstat을 잘못 사용하여 fds를 열 수 있었기 때문입니다.

레코드의 경우, netstat -n | grep TIME_WAIT | wc -l의 출력은 매달려있는 소켓에 대한 파일 설명자를 계산할 때 사용해서는 안됩니다. 이것이 내가 잘못한 것입니다. 대신 lsof 또는 fstat를 사용하십시오.

어쨌든 - 서버의 부하가 큰 상태에서 더 이상 fds가 부족하지 않습니다.

건배

TIME_WAIT 모드에서