최근에는 프로세스를 종료하는 습관이 생겼습니다.
fuser -k -n tcp $PORT
이로 인해 잘못된 프로세스를 종료하기가 어렵습니다. 나는 아직 존재할 수도 있고 존재하지 않을 수도 있고, 올바른 pid를 포함할 수도 있고 포함하지 않을 수도 있는 pid 파일을 조작하는 것보다 이것을 선호합니다(좋아, 여기서는 약간 극적입니다 :-)
그러나 내가 우연히 발견한 일반적인 중지 스크립트는 여전히 pidfile을 사용합니다.
pidfile 방법의 중요한 기능이 누락되었거나 fusion의 잘못된 기능이 누락되었습니까 approach? 내 추측으로 는 fuser사용할 수 없다는 것입니다. 검색 엔진 결과로 보면 bsd, debian, suse, centos, aix, Solaris 등이 사용 가능한 것으로 보입니다.
답변1
명령 fuser옵션은 -n <file|udp|tcp>Linux에만 적용되는 반면, PID 파일 기반 솔루션은 많은 Unix 변형에서 전통적이므로 이식성이 뛰어납니다.
적어도 데비안에서는 명령이 "선택 사항"으로 지정된 패키지 fuser에 있으므로 모든 시스템에 항상 존재할 것이라고 기대할 수는 없습니다.psmisc
답변2
TelcoM이 언급한 것 외에도 이 접근 방식에는 두 가지 잠재적인 문제가 있습니다. 두 가지 모두 소켓 옵션과 관련이 있습니다 SO_REUSEPORT.
이 소켓 옵션을 사용하면 여러 프로세스(모든 프로세스에 이 옵션이 설정되어 있어야 함)가 동일한 포트에 바인딩되고 기본 프로세스에서 전통적으로 수행했던 연결의 로드 밸런싱을 커널로 오프로드할 수 있습니다.
이로 인해 발생하는 두 가지 잠재적인 문제는 다음과 같습니다.
프로세스 기반 병렬 처리(예: NGinx)를 사용하고 이 옵션을 사용하는 서버의 경우 소켓 연결의 PID는 일반적으로 기본 프로세스 자체가 아닌 기본 프로세스의 하위 프로세스입니다. 이 경우 접근
fuser방식은 모든 하위 프로세스를 종료하지만 기본 프로세스에 신호를 보내지 않으므로 서비스가 전혀 종료되지 않거나(기본 프로세스가 하위 프로세스를 다시 시작하는 경우) 서비스가 종료될 수 있습니다. 문제를 일으키는 방법(코드는 자식 프로세스의 종료가 치명적인 오류를 나타낸다고 가정하고 기본 프로세스 자체가 신호를 받은 경우와 다른 종료 경로를 사용할 수 있습니다).이로 인해 원하는 다른 프로그램이 종료될 수 있습니다. 이 시나리오는 나쁜 것은 아니지만(제거할 수 있는 유일한 "다른" 프로그램은 맬웨어일 수 있음) 고려해 볼 가치가 있습니다.