1

I have a python process, which spawns a git (git clone) child process, which in turn spawns several child processes itself. Here, I want to kill all processes in the process tree rooted by git, without killing the python process.

Possible solutions with caveats:

  • Traverse the child process tree of python using /proc/<pid> recursively.

In this case, how can I be sure that any process in this process hierarchy hasn't spawned a child process before it being killed, in which case the child becomes an orphan (race condition)?

  • Kill the process group of the python process, which includes git and every other descendant.

In this case, python process is killed too, which I don't want to happen.

Is there any way to reliably kill all processes in the process hierarchy rooted by the python process, but not the python process itself?

Improve this question
4
  • @terdon - sorry for my bad phrase of the problem. I've completed rewritten the question. Tell me, if you miss any details. Commented Oct 4, 2020 at 15:53
  • Much better, thanks! Now, to make it perfect, can you give us a minimal example that we can run and test our answers? That would be very useful in trying to debug this. Commented Oct 4, 2020 at 16:12
  • 1
    You create a separate process group and put all children in it. And take care to catch and forward the INT signal to the new process group. You should do that not because a kill -pgid will also kill your python (you can just catch the signal), but because it also kill other sibling or parent processes of your python (as any script it was called from, or other processes from the same pipeline). Generally, if you have to care too much about process management and you're not writing the next systemd, it's probably because you're overcomplicating yourself. Commented Oct 5, 2020 at 6:33
  • @StephenKitt The OP already had 2 descendants. Commented Oct 5, 2020 at 7:33

1 Answer 1

Reset to default
1

The pslist package contains rkill which can kill all descendants:

man pslist:

The pslist utility examines the list of current processes to find a specified process and all its descendants. [..]

When invoked as rkill, this utility does not display information about the processes, but sends them all a signal instead. If not specified on the command line, a terminate (SIGTERM) signal is sent.

You only need to give it the pid of git.

(available on ubuntu/arch/etc.)

Improve this answer
5
  • Is it possible that a race condition exist, where a process spawns a child after rkill has done its examination of descendants, but before it has been killed, in which case the child becomes an orphan? Commented Oct 5, 2020 at 6:22
  • I only looked at the source briefly (devel.ringlet.net/sysutils/pslist) - it first collects the pids (proc_get_children_r) and only then kills them. So yes, a race condition is possible with this tool. Commented Oct 5, 2020 at 7:26
  • I know it's off-topic, but will any approach for killing a process tree not be subject to such race condition, when executed from userland? I guess only the kernel will be able to restrict the processes from creating new children, while it kills them. Commented Oct 5, 2020 at 8:41
  • I don't think that's possible. Because if you kill the parent process first, each of children will become orphan, which result in init(8) becomming the new parent process for those children. Thus, you loose the ppid information. Commented Oct 5, 2020 at 10:41
  • Yes, you are correct. This question has already been answered, although not the part about the race condition unix.stackexchange.com/questions/124127/… Commented Oct 5, 2020 at 13:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.