python / python/cpython

multiprocessing.Pool gets stuck indefinitely when the child process is killed manually

Open
#96,062 11 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

topic-multiprocessing type-bug
Dominant language
Python
Stars
77.2k
Forks
36k
PR merge metrics
PR metrics pending

Description

Bug report

When I use multiprocessing.Pool and let processes=1 to execute the task, if I manually kill the child process in the background, the task will not be executed, and the new child process seems to be waiting indefinitely and cannot be terminated.
Here is the example I tested:

import logging
import multiprocessing
import platform
import time
from multiprocessing import Pool

multiprocessing.log_to_stderr().setLevel(logging.DEBUG)


def print_some(i):
    print("Current process name is %s" % multiprocessing.current_process())
    print("--------------"+str(i)+"--------------")
    return "return "+str(i)


def callback_func(n):
    print (n)


if __name__ == "__main__":
    print(platform.python_version())
    multiprocessing.set_start_method('fork')
    p = Pool(1)
    i = 0
    print(p._pool[0].pid)
    while i < 6:
        p.apply_async(print_some, (i, ), callback=callback_func)
        time.sleep(3)
        i = i+1
    print("end")
    print(p._pool[0].pid)
    p.terminate()
    print("close")

and the output is(I manually kill the process 30995):

3.8.2
[DEBUG/MainProcess] created semlock with handle 6
[DEBUG/MainProcess] created semlock with handle 7
[DEBUG/MainProcess] created semlock with handle 10
[DEBUG/MainProcess] created semlock with handle 11
[DEBUG/MainProcess] created semlock with handle 14
[DEBUG/MainProcess] created semlock with handle 15
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-1] child process calling self.run()
30995
Current process name is <ForkProcess name='ForkPoolWorker-1' parent=30994 started daemon>
--------------0--------------
return 0
Current process name is <ForkProcess name='ForkPoolWorker-1' parent=30994 started daemon>
--------------1--------------
return 1
Current process name is <ForkProcess name='ForkPoolWorker-1' parent=30994 started daemon>
--------------2--------------
return 2
Current process name is <ForkProcess name='ForkPoolWorker-1' parent=30994 started daemon>
--------------3--------------
return 3
[DEBUG/MainProcess] cleaning up worker 0
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-2] child process calling self.run()
[DEBUG/MainProcess] terminating pool
[DEBUG/MainProcess] finalizing pool
[DEBUG/MainProcess] helping task handler/workers to finish
[DEBUG/MainProcess] removing tasks from inqueue until task handler finished
[DEBUG/MainProcess] worker handler exiting
[DEBUG/MainProcess] task handler got sentinel
[DEBUG/MainProcess] task handler sending sentinel to result handler
[DEBUG/MainProcess] task handler sending sentinel to workers
[DEBUG/MainProcess] task handler exiting
[DEBUG/MainProcess] result handler got sentinel
end
31000

From the output, when I kill the child process, multiprocessing.Pool does start a new process, but the task cannot continue, and terminate() seems to be stuck somewhere, because my main process is not over, been waiting.
During the running process of the service, the process of crashing is unpredictable, so I did such a test: when using multi-process, what effect will the child process crash have on the program. Finally found such a problem.

Your environment

  • CPython versions tested on: Python3.8.2
  • Operating system and architecture:MacOS10.15.7 or ubuntu16.0.4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the multiprocessing.Pool behavior shown in the reproducer, using the reported Python 3.8.2 environments on macOS or Ubuntu. Re-run the example while killing the worker, then trace worker replacement and terminate() handling. Done means the queued task can proceed after a worker is killed and pool termination does not wait indefinitely.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.