분명히 kill(0)을 효과적으로 지원하려면 커널이 프로세스 그룹의 프로세스를 추적해야 합니다. 그러나 해당 정보는 어떤 방식으로도 사용자 공간에 노출되지 않습니다. 이 정보를 얻으려면 전체 procfs 트리를 반복하고 pgid를 확인해야 합니다.
이는 Linux, *BSD 등에 해당됩니다. 내가 확인한 모든 *nix 시스템에는 이 문제가 있었습니다. 왜 이렇게 설계되었나요?
편집하다:kill(0) 예제가 이해되도록 질문을 변경하십시오.
답변1
출력을 필터링하여 특정 그룹의 모든 프로세스를 나열할 수 있습니다 ps.
ps -e -o pgid,pid | awk -v p=1234 '$1 == p {print $2}'
PGID로 직접 필터링하는 옵션 은 없습니다 ps. 아마도 유용하지 않기 때문일 것입니다.
후드 아래에 무엇이 있는지는 ps중요하지 않습니다.
kill -- -1234그러나 프로세스 그룹의 프로세스를 자동으로 나열하는 방법이 있더라도 이점은 무엇입니까 ? 목록을 처리할 때 목록이 불완전하거나 종료되고 PID가 재사용된 프로세스가 포함되어 있을 수 있습니다.
프로세스 그룹의 프로세스 집합에 대해 유용한 작업을 수행하려면 커널은 그룹 구성원을 나열하는 인터페이스뿐만 아니라 작업을 수행하는 인터페이스를 노출해야 합니다. 유일한 인터페이스는 프로세스에 신호를 보내는 것입니다.
답변2
Linux의 명령줄에서 (또는 ) 플래그 pgrep와 함께 procps-ng를 사용할 수 있습니다.--pgroup-g
답변3
PID 0(영)으로 신호를 보내면 보낸 사람과 동일한 프로세스 그룹에 속한 모든 프로세스에 신호가 전달됩니다. 현재 프로세스 그룹이 아닌 프로세스 그룹은 프로세스 그룹 ID가 어디에 있는지 를 통해 kill(-PGID)(또는 kill -- -PGID셸에서) 신호를 보낼 수 있습니다.PGID
PID의 프로세스 그룹은 함수에 의해 반환되며 getpgid(), 이를 통해 현재 프로세스의 프로세스 그룹을 찾을 수 있다 getpgrp().
쉘에서는 다음을 사용할 수 있습니다.
$ ps -opid,pgid,command
현재 세션의 PID, PGID(프로세스 그룹 ID) 및 명령줄을 가져옵니다.
이는 다음과 같은 결과를 반환할 수 있습니다.
PID PGID COMMAND
20716 20716 -ksh93 (ksh93)
83662 83662 -ksh93 (ksh93)
4322 4322 /usr/X11R6/bin/xclock
5374 5374 tmux: client (/tmp/tmux-11000/default) (tmux)
78747 78747 -ksh93 (ksh93)
29298 29298 ps -opid
63563 63563 -ksh93 (ksh93)
63327 63327 mutt
21790 21790 -ksh93 (ksh93)
64493 64493 /bin/sh /usr/X11R6/bin/startx
14485 64493 xinit /home/kk/.xinitrc -- /usr/X11R6/bin/X :0 -auth /home/kk/.serverauth.E3cwuT5FZR
93531 93531 sh /home/kk/.xinitrc
48598 93531 flwm
28154 93531 xterm
73053 93531 xterm
질문을 명확히 한 후:
이것목적프로세스 그룹의 목적은 모든 구성원에게 신호를 보낼 수 있는 것입니다.아니요각 구성원의 프로세스 ID를 알아보세요.
프로세스 그룹 개념이 없으면 시스템의 모든 프로세스를 가져와서 (상위 프로세스 ID를 사용하여) 프로세스 간의 관계를 찾아내고 관련 프로세스를 반복하여 각 프로세스에 신호를 보내야 합니다.
커널은 이 작업을 수행하지만 프로세스 그룹을 알고 추적하므로 반복할 필요가 없습니다.모두프로세스는 해당 그룹의 구성원을 통해서만 프로세스 그룹에 신호를 보냅니다.
프로세스 그룹 ID로 인해예사용자에게 노출, 쿼리만 가능하나프로세스는 해당 그룹의 모든 프로세스에 신호를 보내기 전에 프로세스 그룹 ID를 찾아야 합니다.