Mac M1上Celery任务无法运行：ForkPoolWorker触发SIGSEGV错误

问题背景 #

在Mac M1机器上运行Django+Celery任务时，频繁出现以下报错：

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
[2023-11-20 15:51:19,174: ERROR/MainProcess] Process 'ForkPoolWorker-8' pid:5547 exited with 'signal 11 (SIGSEGV)'

系统版本为MacOS Sonoma 14.2 Beta，曾通过设置OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES临时解决问题，但后续故障复现。

可行解决方案 #

1. 切换Celery Worker的进程启动方式 #

Mac ARM架构（M1/M2）对fork机制的兼容性较差，尤其是涉及CoreFoundation组件的场景。直接修改Celery启动命令，指定非fork的进程池：

• 开发环境推荐使用solo池（单进程模式，简单稳定）：

  celery -A 你的Django项目名 worker --loglevel=info --pool=solo
  

• 生产/并发场景可使用gevent池（需先安装依赖）：

  pip install gevent
  celery -A 你的Django项目名 worker --loglevel=info --pool=gevent
  

2. 确保环境变量全局生效 #

之前临时生效可能是环境变量仅作用于单次会话，可尝试：

• 启动Celery时直接注入变量：

  OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES celery -A 你的Django项目名 worker --loglevel=info
  

• 全局配置环境变量：
  编辑~/.zshrc或~/.bash_profile（根据你使用的shell），添加：

  export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
  

  执行source ~/.zshrc（对应你的配置文件）使设置生效，之后重启Celery服务。

3. 延迟初始化任务中的敏感依赖 #

排查Celery任务中是否使用了涉及系统API、图像处理类的第三方库（如PIL、pyobjc相关组件），这类库在模块级别初始化时会绑定CoreFoundation上下文，fork后易引发冲突。

将这类库的导入或初始化操作移至任务函数内部，避免在进程fork前创建敏感上下文：

# 错误示例：模块级别导入敏感库
from PIL import Image

@shared_task
def process_image(img_path):
    img = Image.open(img_path)
    # 处理逻辑

# 正确示例：任务内延迟初始化
@shared_task
def process_image(img_path):
    from PIL import Image
    img = Image.open(img_path)
    # 处理逻辑

4. 更新系统版本 #

当前使用的是Beta版系统，Apple可能在后续版本修复ARM架构下fork机制的兼容性问题，建议更新到最新的正式版或Beta版本后重试。

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