Ubuntu에서는 일부 서버/데몬과 일부 클라이언트를 로컬로 실행하는 경우가 많습니다. 서버/데몬 및 클라이언트는 모든 프로그램(emacs 데몬 및 클라이언트, Screen 데몬 및 클라이언트, 누군가가 작성한 서버 및 클라이언트)일 수 있으며 이름이 어떻게 지정되는지 모른다고 가정합니다.
클라이언트 프로세스의 PID만 제공하면 서버/데몬 프로세스의 PID를 찾을 수 있는 방법이 있습니까?
서버/데몬의 PID만 주어진 모든 클라이언트의 PID를 찾는 방법이 있습니까?
제가 요구하는 것이 불가능하다면, 최대한 일반적이라는 목표를 달성하기 위해 추가로 필요한 최소한의 정보는 무엇입니까?
감사해요.
답변1
대부분의 IPC(프로세스 간 통신) 형식은 일부 유틸리티를 사용하여 추적할 수 있습니다. 소켓(네트워크 소켓 및 UNIX 소켓)은 매우 일반적이며 몇 가지 일반적인 도구를 사용하여 추적할 수 있습니다. 사용법 예를 살펴 보겠습니다 netstat -ap
.
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5000 0.0.0.0:* LISTEN 810/python3
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 858/nginx: master process
<snip>
tcp 0 0 127.0.0.1:46858 127.0.0.1:5000 ESTABLISHED 860/nginx: worker process
<snip>
tcp 0 0 127.0.0.1:5000 127.0.0.1:46858 ESTABLISHED 810/python3
PID 860과 810을 가진 두 프로세스가 통신 중입니다. 이 예에서는 810이 서버입니다. 우리는 netstat
출력을 분석하거나 시각적으로 이를 통해 grep
이를 확인할 수 있습니다.
또한 클라이언트가 PID 810에 대해 무엇을 말하고 있는지 보고 싶다고 가정하면 다음과 같이 할 수 있습니다 lsof -p 810
.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
<snip>
python3 810 user 8u IPv4 35702 0t0 TCP 127.0.0.1:5000 (LISTEN)
python3 810 user 10u IPv4 4682120 0t0 TCP 127.0.0.1:5000->127.0.0.1:46858 (ESTABLISHED)
여기서 우리 프로세스가 통신하고 있는 엔드포인트는 식별할 수 있지만 PID는 식별할 수 없습니다. 다른 PID를 식별하려면 다음을 수행할 수 있습니다 lsof -i :46858
.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python3 810 user 10u IPv4 4682120 0t0 TCP localhost:5000->localhost:46858 (ESTABLISHED)
nginx 860 nginx 18u IPv4 4681280 0t0 TCP localhost:46858->localhost:5000 (ESTABLISHED)
출력의 아래쪽에는 netstat
UNIX 소켓이 있습니다.
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
<snip>
unix 2 [ ACC ] STREAM LISTENING 21936 1/systemd /run/dbus/system_bus_socket
<snip>
unix 3 [ ] STREAM CONNECTED 28918 648/dbus-daemon /run/dbus/system_bus_socket
두 프로세스 모두 UNIX 소켓을 사용하고 있음을 알 수 있습니다 /run/dbus/system_bus_socket
. 따라서 프로세스 중 하나를 알고 있으면 이를 보고 다른 측면을 식별할 수 있어야 합니다. lsof
이 경우 다시 사용할 수 있습니다 lsof /run/dbus/system_bus_socket
.
이것이 약간 복잡하다는 것을 알고 있지만 도움이 되기를 바랍니다. 일종의 파일/핸들(예: 파이프)을 사용하는 다른 유형의 IPC lsof
도 추적에 사용할 수 있습니다.
답변2
나는 썼다픽셀이 목적을 위해 (무엇보다도).
px
(다른 유용한 것들 중에서) 당신이 통신하고 있는 다른 프로세스가 무엇인지 알려줄 것입니다.
샘플 출력, IPC 추적을 보려면 맨 아래로 스크롤:
~ $ sudo px 49903
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome
--enable-audio-service-sandbox
--origin-trial-disabled-features=MeasureMemory
kernel(0) root
launchd(1) root
--> Google Chrome(49903) johan
Google Chrome Helper(49922) johan
Google Chrome Helper(49958) johan
Google Chrome Helper (GPU)(49920) johan
Google Chrome Helper (Renderer)(49935) johan
Google Chrome Helper (Renderer)(49936) johan
Google Chrome Helper (Renderer)(49943) johan
Google Chrome Helper (Renderer)(49950) johan
Google Chrome Helper (Renderer)(49951) johan
Google Chrome Helper (Renderer)(49957) johan
Google Chrome Helper (Renderer)(64466) johan
Google Chrome Helper (Renderer)(75275) johan
Google Chrome Helper (Renderer)(76225) johan
Google Chrome Helper (Renderer)(76650) johan
Google Chrome Helper (Renderer)(76668) johan
Google Chrome Helper (Renderer)(76712) johan
7d21h ago Google Chrome was started, at 2020-09-04T19:15:03+02:00.
0.3% has been its average CPU usage since then, or 32m25s/7d21h
Other processes started close to Google Chrome(49903):
Google Chrome/chrome_crashpad_handler(49912) was started just after Google Chrome(49903)
AlertNotificationService(49924) was started 1.0s after Google Chrome(49903)
Google Chrome Helper(49922) was started 1.0s after Google Chrome(49903)
Google Chrome Helper (GPU)(49920) was started 1.0s after Google Chrome(49903)
Google Chrome Helper (Renderer)(49935) was started 1.0s after Google Chrome(49903)
Google Chrome Helper (Renderer)(49936) was started 1.0s after Google Chrome(49903)
VTDecoderXPCService(49934) was started 1.0s after Google Chrome(49903)
Users logged in when Google Chrome(49903) started:
johan
2020-09-12T16:28:30.587930: Now invoking lsof, this can take over a minute on a big system...
2020-09-12T16:28:30.901834: lsof done, proceeding.
Others sharing this process' working directory (/)
Working directory too common, never mind.
File descriptors:
stdin : [CHR] /dev/null
stdout: [CHR] /dev/null
stderr: [CHR] /dev/null
Network connections:
[IPv4] *:* (LISTEN)
Inter Process Communication:
mDNSResponder(291): [unix] ->0x2b8028c5de1ab5b
mDNSResponder(291): [unix] ->0x2b8028c5de1c5eb
For a list of all open files, do "sudo lsof -p 49903", or "sudo watch lsof -p 49903" for a live view.
~ $