我们可以在同一台机器上找出彼此的服务器/守护进程和客户端进程吗?

我们可以在同一台机器上找出彼此的服务器/守护进程和客户端进程吗?

在 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.

我意识到这有点复杂,但我希望它能有所帮助。请注意,使用某种文件/句柄(例如管道)的其他类型的 IPClsof也可以使用进行跟踪。

答案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.
~ $

相关内容