`OSError: AF_UNIX path too long` regression in `forkserver`

[mgorny]

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 long

Apparently 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

• gh-149527: fix creation of temporary socket files post GH-148578 #149597

[picnixz]

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]

So I fixed the issue but note that in your case the temporary directory will be switched to /tmp/ instead of $TMPDIR because the path is too long. It will be /tmp/pymp-XXXXXXXX/sock-XXXXXXXXXXXX.

[picnixz]

Note: I centralized the constants that we use in multiprocessing.util so 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]

Thanks!