소켓을 테스트할 때 lsof가 불평을 멈추게 하려면 어떻게 해야 합니까?

소켓을 테스트할 때 lsof가 불평을 멈추게 하려면 어떻게 해야 합니까?

특정 소켓을 수신하는 프로세스가 fuser대상 시스템에는 없지만 lsof존재하는지 테스트해야 합니다. 다음 명령을 실행합니다.

lsof -tU /path/to/socket

리스너의 PID를 나열합니다. 이는 괜찮지만 lsof상태로 종료됩니다 1. 무엇이 잘못되었는지 확인하기 위해 명령을 변경했습니다.

lsof -tUV /path/to/socket

PID를 다시 나열하고 다음도 추가합니다.

lsof: /path/to/socket에 사용된 파일이 없습니다.

0"파일 사용"이 발생할 때 종료 되도록 추가 검사를 억제하는 방법이 있습니까?하다소켓에서 리스너를 찾았습니까? 매뉴얼 페이지를 살펴봤지만 원하는 내용을 찾을 수 없습니다. 다음과 같이 현명하게 사용하고 싶습니다.

sock=/path/to/socket
if [[ ! -S $sock ]] || ! lsof -tU $sock &>/dev/null; then
    # task to activate socket listener
fi

답변1

최신 버전의 시스템 ss(예: Debian 10 시스템 iproute2-ss190107)을 사용하는 경우 다음을 사용할 수 있습니다 ss.lsof

sock=/path/to/socket
ino=$(stat -c 'ino:%i' "$sock") && ss -elx | grep -w "$ino"

sock=/path/to/socket
if ino=$(stat -c 'ino:%i' "$sock") && ss -elx | grep -qw "$ino"
then
   # yeah, somebody's listening on $sock
fi

여기서 주목해야 할 두 가지 중요한 사항이 있습니다.

  1. Unix 소켓의 실제 주소는 device,inode숫자의 튜플입니다.경로명이 아님. 소켓 파일이 다음과 같은 경우움직이는, 수신 중인 서버가 무엇이든 새 경로를 통해 액세스할 수 있습니다. 소켓 파일이 다음과 같은 경우삭제됨, 다른 서버가 동일한 경로에서 수신 대기할 수 있습니다(이것이 보안 측면에서 Unix 소켓에 대한 디렉토리 권한이 중요한 이유입니다). lsof이 문제는 처리할 수 없으며 불완전하거나 잘못된 데이터가 반환될 수 있습니다.

  2. ss이는 그 자체로 문제가 있으며 unix_diagnetlink 인터페이스는 ssLinux 커널에서 내부적으로 사용되는 형식을 사용하여 장치 번호를 반환하지만 시스템 호출 인터페이스에서 사용하는 형식 ss(예:)이라고 가정하기 stat(2)때문에 위의 출력이 관리됩니다. 그러나 어느 날 문제를 해결하기로 결정할 수도 있으므로 문제를 해결하는 것은 현명하지 못할 수도 있습니다. 따라서 해야 할 유일한 일은 이를 순수한 쓰레기로 처리하고 동일한 inode를 갖지만 다른 파일 시스템에 있는 두 개의 소켓 파일의 위험을 감수하는 것입니다.dev:ss -elxdev:위의 테스트는 처리할 수 없습니다.


위의 사항 중 어느 것도 중요하지 않은 경우 똑같이 나쁜 작업을 수행할 수 있습니다 lsof(처음에 소켓이 바인딩된 경로와 일치).

sock=/path/to/socket
ss -elx | grep " $sock "

Centos 7과 같은 이전 시스템에서도 작동합니다. 적어도 이것은 목록만 나열할 수 있다는 장점이 있습니다.듣다소켓;-)

답변2

내가 한 일은 다음과 같습니다.

if ! [[ -S $SSH_AUTH_SOCK && -n "`ss -xa 2>/dev/null | grep -F $SSH_AUTH_SOCK 2>/dev/null`" ]]; then
    # task to activate socket listener
fi

추악하지만 기능적입니다.

관련 정보