Clearly, in order to support kill(0) efficiently, the kernel must keep track of the processes in a process group. But that information is not exposed at all, in any way to the user space. To get that information, one would have to iterate over the entire procfs tree, and check the pgid.

This is true for Linux, *BSD, etc. All *nix systems I checked have this problem. Why are they designed this way?

EDIT: Change the question so the kill(0) example makes sense.

  • 1
    The PPID is a direct relation. I don't understand your problem. Commented May 6, 2017 at 0:47
  • You need to iterate over all process to get child process of a single process, this is obviously not optimal
    – nialv7
    Commented May 6, 2017 at 1:49
  • 1
    It is obviously taking much longer to worry about this than it will even take your computer to process it. Commented May 6, 2017 at 2:08
  • 2
    Your question is based on a false premise. kill 0 doesn't involve child or parent PIDs, it involves the process group.
    – phemmer
    Commented May 6, 2017 at 2:29
  • @JuliePelletier Your argument makes 0 sense. Currently you need to make thousands of system calls with potential race conditions, to get information that is readily available in the kernel.
    – nialv7
    Commented May 6, 2017 at 10:03

3 Answers 3


You can list all processes in a given group by filtering the output of ps.

ps -e -o pgid,pid | awk -v p=1234 '$1 == p {print $2}'

There's no ps option to directly filter by PGID, probably because it isn't useful very often.

What ps does under the hood doesn't really matter.

This is not atomic, unlike kill -- -1234. But even if there was a way to atomically list processes in a process group, what good would it be? By the time you process the list, it may be incomplete or include processes that are dead and whose PID has been reused.

To do anything useful with the set of processes in a process group, the kernel would have to expose an interface that performs the action, not just an interface that lists the members of the group. The only such interface is to send a signal to the processes.

  • Change to "ps -eo pid,pgid" to get all processes on the system, not just the current session.
    – Todd Freed
    Commented Nov 11, 2017 at 0:14
  • Change to ps -e -o pgid,pid | awk -v p=1234 '$1 == p {print $2}' to get the correct result - column order in the ps output produced by the original answer is wrong. Commented Feb 15, 2018 at 14:56

From the command line on Linux, one can use pgrep from procps-ng with the --pgroup (or -g) flag.


When sending a signal to PID 0 (zero), the signal is delivered to all processes that are members of the same process group as the sender. A process group other than the current one may be signalled with kill(-PGID) (or kill -- -PGID in the shell) where PGID is the process group ID.

The process group of a PID is returned by getpgid() function, and the process group of the current process may be found with getpgrp().

In the shell, you may use

$ ps -opid,pgid,command

to get the PID, PGID (process group ID) and command line of your current session.

This may return something like

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

After a clarification of the question:

The purpose of a process group is to be able to send a signal to all its members without knowing the process IDs of each individual member.

Without a process group concept, one would have to get all the processes on the system, figure out how they are related (using the parent process IDs) and iterate over the relevant processes, sending each the signal.

The kernel does this, but it knows and keeps track of process groups, so it will never have to iterate over all processes to send a signal to a process group, only over the members of the group.

Since the process group ID is exposed to the user, one would only have to query one process for its process group ID before being able to send a signal to all processes in that group.

  • I already know this, this is not what I asked.
    – nialv7
    Commented May 6, 2017 at 9:18
  • 2
    @yshui I have updated my answer. It would additionally be interesting to know what specific issue you are trying to solve.
    – Kusalananda
    Commented May 6, 2017 at 11:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .