Skip to content

sys.argv no longer correct during main module execution using forkserver #143706

@tpwrules

Description

@tpwrules

Bug report

Bug description:

The following code, invoked with python3 ~/test.py foo:

import multiprocessing
import sys

print("args in module", sys.argv[1:])

def fun():
    print("args in fun", sys.argv[1:])

if __name__ == "__main__":
    multiprocessing.set_start_method("forkserver")

    fun()

    p = multiprocessing.Process(target=fun)
    p.start()
    p.join()

prints the following results on Python 3.12, 3.13.4, and 3.14.0b3:

args in module ['foo']
args in fun ['foo']
args in module ['foo']
args in fun ['foo']

but on Python 3.13.11 and 3.14.2 prints the following results:

args in module ['foo']
args in fun ['foo']
args in module []
args in fun ['foo']

For whatever reason, these latter versions change forkserver to set up sys.argv after the main module is imported, instead of before. As far as I can tell, the former results are always printed using spawn; that always sets up sys.argv before the main module is imported.

If the code depends on sys.argv in the main module, then the subprocess does not do the same thing as the main process and bad things can happen.

This change tripped me up when fixing a program for the new forkserver default. It's unclear if it's a bug, because I admit our program is naughty about running code in a module like this, but this may be something to fix and at least may serve as documentation of a pitfall for others even if there is nothing to change.

CPython versions tested on:

3.12, 3.13, 3.14

Operating systems tested on:

Linux

Linked PRs

Metadata

Metadata

Assignees

Labels

stdlibStandard Library Python modules in the Lib/ directorytopic-multiprocessingtype-bugAn unexpected behavior, bug, or error

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions