특정 소켓을 수신하는 프로세스가 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
여기서 주목해야 할 두 가지 중요한 사항이 있습니다.
Unix 소켓의 실제 주소는
device,inode
숫자의 튜플입니다.경로명이 아님. 소켓 파일이 다음과 같은 경우움직이는, 수신 중인 서버가 무엇이든 새 경로를 통해 액세스할 수 있습니다. 소켓 파일이 다음과 같은 경우삭제됨, 다른 서버가 동일한 경로에서 수신 대기할 수 있습니다(이것이 보안 측면에서 Unix 소켓에 대한 디렉토리 권한이 중요한 이유입니다).lsof
이 문제는 처리할 수 없으며 불완전하거나 잘못된 데이터가 반환될 수 있습니다.ss
이는 그 자체로 문제가 있으며unix_diag
netlink 인터페이스는ss
Linux 커널에서 내부적으로 사용되는 형식을 사용하여 장치 번호를 반환하지만 시스템 호출 인터페이스에서 사용하는 형식ss
(예:)이라고 가정하기stat(2)
때문에 위의 출력이 관리됩니다. 그러나 어느 날 문제를 해결하기로 결정할 수도 있으므로 문제를 해결하는 것은 현명하지 못할 수도 있습니다. 따라서 해야 할 유일한 일은 이를 순수한 쓰레기로 처리하고 동일한 inode를 갖지만 다른 파일 시스템에 있는 두 개의 소켓 파일의 위험을 감수하는 것입니다.dev:
ss -elx
dev:
위의 테스트는 처리할 수 없습니다.
위의 사항 중 어느 것도 중요하지 않은 경우 똑같이 나쁜 작업을 수행할 수 있습니다 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
추악하지만 기능적입니다.