Repository navigation
OSError: AF_UNIX path too long regression in forkserver #149527
Description
Bug report
Bug description:
Since fd81246 (in 3.14 as e590f00), we're seeing Gentoo Portage randomly fail with:
Traceback (most recent call last):
File "/usr/lib/portage/python3.14/ebuild-ipc.py", line 303, in <module>
sys.exit(ebuild_ipc_main(sys.argv[1:]))
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "/usr/lib/portage/python3.14/ebuild-ipc.py", line 299, in ebuild_ipc_main
return ebuild_ipc.communicate(args)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/usr/lib/portage/python3.14/ebuild-ipc.py", line 151, in communicate
lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
File "/usr/lib/python3.14/site-packages/portage/locks.py", line 184, in lockfile
lock = _lockfile_iteration(
mypath,
...<3 lines>...
flags=flags,
)
File "/usr/lib/python3.14/site-packages/portage/locks.py", line 314, in _lockfile_iteration
locking_method = _get_lock_fn()
File "/usr/lib/python3.14/site-packages/portage/locks.py", line 96, in _get_lock_fn
if _test_lock_fn(_lockf_test_lock_fn):
~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.14/site-packages/portage/locks.py", line 128, in _test_lock_fn
proc.start()
~~~~~~~~~~^^
File "/usr/lib/python3.14/multiprocessing/process.py", line 121, in start
self._popen = self._Popen(self)
~~~~~~~~~~~^^^^^^
File "/usr/lib/python3.14/multiprocessing/context.py", line 230, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/usr/lib/python3.14/multiprocessing/context.py", line 306, in _Popen
return Popen(process_obj)
File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__
super().__init__(process_obj)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/usr/lib/python3.14/multiprocessing/popen_fork.py", line 20, in __init__
self._launch(process_obj)
~~~~~~~~~~~~^^^^^^^^^^^^^
File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 51, in _launch
self.sentinel, w = forkserver.connect_to_new_process(self._fds)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
File "/usr/lib/python3.14/multiprocessing/forkserver.py", line 89, in connect_to_new_process
self.ensure_running()
~~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.14/multiprocessing/forkserver.py", line 167, in ensure_running
listener.bind(address)
~~~~~~~~~~~~~^^^^^^^^^
OSError: AF_UNIX path too longApparently in this case the resulting path was:
/tmp/mgorny-dev-scripts/portage/dev-python/trove-classifiers-2026.5.7.17/temp/pymp-o2g23iqr/sock-d559f6e62fa1
Note that tempfile.mktemp() used to append 8 ASCII characters, while this logic appends 12 hex digits, so the logic introduced in 1a07a01 would be off by 4 now.
CPython versions tested on:
3.14, CPython main branch
Operating systems tested on:
Linux
Linked PRs
Metadata
Metadata
Assignees
Labels
Projects
- Status
Activity
picnixz commentedon May 8, 2026
Ah so the computation was not updated. To avoid future issues I am going to hardcode the number of random bytes we use and add a comment. I will address this tomorrow
cc @gpshead
picnixz commentedon May 9, 2026
So I fixed the issue but note that in your case the temporary directory will be switched to
/tmp/instead of$TMPDIRbecause the path is too long. It will be/tmp/pymp-XXXXXXXX/sock-XXXXXXXXXXXX.picnixz commentedon May 9, 2026
Note: I centralized the constants that we use in
multiprocessing.utilso that we just need to update them to bump security stuff instead of changing them one by one (and the comments). I can hardcode them but we won't get bitten by such changes in the future (at least we know what will needs to be changed!)mgorny commentedon May 9, 2026
Thanks!
python3: bump to 3.14.5