Title: multiprocessing cannot spawn grandchild from a Windows service
Type: behavior Stage: resolved
Components: Library (Lib), Windows Versions: Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: davin Nosy List: davin, paul.moore, schlamar, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2016-02-25 09:56 by schlamar, last changed 2017-05-19 00:42 by davin. This issue is now closed.

File name Uploaded Description Edit schlamar, 2016-02-25 09:56
issue_26434_fix_win32_service_parent_origin.patch davin, 2016-02-26 23:45 patch sans test for 2.7 branch
Pull Requests
URL Status Linked Edit
PR 1167 merged python-dev, 2017-04-18 07:39
Messages (9)
msg260846 - (view) Author: Marc Schlaich (schlamar) * Date: 2016-02-25 09:56
This is a follow up of #5162.

There are some occasions where you can still run into this issue. One example is if you want to spawn a new multiprocessing.Process as a child of a multiprocessing.Process:

      - multiprocessing.Process
        - multiprocessing.Process (does not start!)

Attached is a test case. If you run this in pywin32 service debug mode, you see that the process crashes with:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Python27\lib\multiprocessing\", line 380, in main
      File "C:\Python27\lib\multiprocessing\", line 503, in prepare
        file, path_name, etc = imp.find_module(main_name, dirs)
    ImportError: No module named PythonService

In get_preparation_data is the following state:

  WINEXE: False
  _python_exe: C:\Python27\python.exe

And so you get as preparation data:

  {'authkey': '...', 'sys_path': [...], 'name': 'test', 'orig_dir': '...', 'sys_argv': ['C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe'], 'main_path': 'C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe', 'log_to_stderr': False}

A workaround for me is patching `get_preparation_data` as follows:

    import multiprocessing.forking

    _org_get_preparation_data = multiprocessing.forking.get_preparation_data

    def _get_preparation_data(*args):
        data = _org_get_preparation_data(*args)
        main_path = data.get('main_path')
        if main_path is not None and main_path.endswith('exe'):
        return data

    multiprocessing.forking.get_preparation_data = _get_preparation_data

BTW, the test case does not run on Python 3.5, but starting the service manually did work. So this is probably a Python 2 issue only.
msg260895 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2016-02-26 16:33
I can reproduce the problem under Windows 7.  Thank you for your example and description -- they were very helpful.

Detection that the original parent was PythonService.exe is necessary to avoid undoing the paths set appropriately for running under a service.  The current code only detects the immediate parent.

Modifying get_preparation_data() in lib/multiprocessing/ to perform an additional test on the inherited values from the original parent's sys.argv (available via the preparation_data key 'sys_argv') would resolve this:
    if not d['sys_argv'][0].lower().endswith("pythonservice.exe"):

Potential complications to existing code appear very unlikely given its nature.

Patch forthcoming after running tests unless someone wants to beat me to it.
msg260910 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2016-02-26 23:45
Attached is a patch for the 2.7 branch which adds the check described in the previous message.

I don't see a reasonable way to provide an accompanying test because it requires registering a win32 service (requiring administrative privileges) temporarily to attempt to provoke the issue.

Can I request that someone else run the full regression tests on this patch?  I am unable to complete a standard run of tests as my Windows 7 development system is set up for building Python 3.x (newer Visual Studio) and am hesitant to fight with Visual Studio configurations.
msg261149 - (view) Author: Marc Schlaich (schlamar) * Date: 2016-03-03 08:31
I can confirm that this patch is working.

Maybe the test case can be modified to simulate a "pythonservice.exe" run (by patching sys.executable or something like that) so it can be run without admin privileges.
msg261165 - (view) Author: Marc Schlaich (schlamar) * Date: 2016-03-03 13:44
We have some business privilege management solution running which might have corrupted the installation. As no one else is reporting this issue, this is my best guest for this phenomena and I'm going to close this issue.
msg261166 - (view) Author: Marc Schlaich (schlamar) * Date: 2016-03-03 13:45
Wrong bug...
msg292967 - (view) Author: Marc Schlaich (schlamar) * Date: 2017-05-04 06:52
I opened a PR on GitHub, please review.
msg293945 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2017-05-19 00:40
New changeset c47c315812b1fa9acb16510a7aa3b37d113def48 by Davin Potts (Marc Schlaich) in branch '2.7':
bpo-26434: Fix multiprocessing grandchilds in a Windows service (GH-1167)
msg293946 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2017-05-19 00:42
Patch committed in 2.7 branch.

Thanks for your help, Marc.
Date User Action Args
2017-05-19 00:42:32davinsetstatus: open -> closed
resolution: fixed
messages: + msg293946

stage: patch review -> resolved
2017-05-19 00:40:19davinsetmessages: + msg293945
2017-05-04 06:52:05schlamarsetmessages: + msg292967
2017-04-18 07:39:14python-devsetpull_requests: + pull_request1297
2016-03-03 13:45:05schlamarsetstatus: closed -> open

messages: + msg261166
2016-03-03 13:44:21schlamarsetstatus: open -> closed

messages: + msg261165
2016-03-03 08:31:11schlamarsetmessages: + msg261149
2016-02-26 23:45:04davinsetfiles: + issue_26434_fix_win32_service_parent_origin.patch
keywords: + patch
messages: + msg260910

stage: needs patch -> patch review
2016-02-26 16:33:17davinsetnosy: + davin
messages: + msg260895

assignee: davin
type: crash -> behavior
stage: needs patch
2016-02-25 09:56:47schlamarcreate