Можем ли мы обнаружить сервер / демон и клиентские процессы друг от друга на одной и той же машине?
Я не уверен, что понимаю вашу потребность в одном цикле. Вы могли бы получить тот же результат, используя два последовательных цикла, как здесь
for MASTER_CLUSTER in $MASTER_CLUSTERS
do
echo "Master cluster boxes are ${!MASTER_CLUSTER}"
done
for SLAVE_CLUSTER in $SLAVE_CLUSTERS
do
echo "Slave cluster boxes are ${!SLAVE_CLUSTER}"
done
или если значения должны чередоваться, то
for MASTER_CLUSTER in $MASTER_CLUSTERS
do
echo "Master cluster boxes are ${!MASTER_CLUSTER}"
for SLAVE_CLUSTER in $SLAVE_CLUSTERS
do
echo "Slave cluster boxes are ${!SLAVE_CLUSTER}"
done
done
Большинство форм 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.
Я написал px для этой цели (среди прочих ).
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.
~ $