GitHub Actions macOS环境下Torch随机出现RuntimeError: Connection refused问题咨询

我们正在开发一个强化学习项目，使用GitHub Actions搭建测试CI系统，在Linux和macOS平台运行单元测试。发现以下错误仅在macOS环境下随机出现（手动重新运行任务即可通过），且无法在本地复现，对应的单元测试文件为tests/algo/test_pbt.py。

错误栈 #

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/miniconda/lib/python3.9/multiprocessing/spawn.py", line 116, in spawn_main
    exitcode = _main(fd, parent_sentinel)
  File "/usr/local/miniconda/lib/python3.9/multiprocessing/spawn.py", line 126, in _main
    self = reduction.pickle.load(from_parent)
  File "/usr/local/miniconda/lib/python3.9/site-packages/torch/multiprocessing/reductions.py", line 322, in rebuild_storage_filename
    storage = torch.UntypedStorage._new_shared_filename_cpu(manager, handle, size)
RuntimeError: Connection refused

咨询问题 #

• 是否有人遇到过该问题？
• 该问题由我方代码导致还是GitHub Actions环境导致？
• 若为我方问题，如何在GitHub Actions黑盒环境下调试（本地无法复现）？
• 若为GitHub Actions环境问题，有何优雅的解决方式？

1. 是否有人遇到过该问题？
   是的，不少开发者在使用PyTorch多进程配合GitHub Actions的macOS runner时遇到过类似问题。这类问题通常和macOS runner的资源限制、共享内存/文件系统竞争，或是PyTorch多进程spawn模式下的pickle通信超时有关。

2. 问题归因
   大概率是GitHub Actions的macOS环境导致，但也不排除代码存在依赖环境时序的潜在问题：

• 环境侧：GitHub Actions的macOS runner属于共享资源，CPU、内存或文件锁的竞争可能导致PyTorch多进程间的共享存储连接超时；macOS的系统级限制（如进程间通信的端口/句柄限制）也可能随机触发该错误。
• 代码侧：如果测试中存在未正确同步的多进程操作，比如在子进程初始化前就尝试共享PyTorch张量，可能在资源紧张的环境下暴露问题，但本地环境资源充足所以不会触发。

3. GitHub Actions环境下的调试方案

• 增加调试日志：在测试代码中添加详细日志，记录进程启动时间、共享存储创建时序等，在CI任务中输出这些日志，方便定位触发错误的场景。
• 强制重试+保留环境：在GitHub Actions配置中，给macOS测试任务添加自动重试机制（比如用重试脚本配合任务配置），同时用actions/upload-artifact保存测试失败时的日志、进程状态文件等。
• 模拟资源紧张环境：本地尝试限制CPU/内存（比如用macOS的launchctl limit工具），复现资源竞争场景，看是否能触发错误。
• 使用远程调试会话：通过mxschmitt/action-tmate在测试失败时启动远程终端，直接登录到runner环境中排查实时状态。

4. 环境问题的优雅解决方式

• 自动重试：在GitHub Actions工作流文件中，给macOS测试步骤添加重试逻辑，比如用nccgroup/action-retry动作设置3次重试，避免偶然失败阻断CI流程。
• 调整多进程启动方式：将PyTorch的多进程启动模式从spawn改为fork（注意：仅适用于非CUDA场景，CUDA环境必须用spawn），减少pickle通信的依赖。
• 升级runner版本：使用runs-on: macos-13或更高版本的runner，新版本的资源限制更宽松，能降低这类问题的触发概率。
• 隔离共享存储：修改测试代码，避免使用PyTorch的共享文件存储，改用内存中的张量传递，减少跨进程的文件系统依赖。

内容的提问来源于stack exchange，提问作者Ming Wang