Celery worker调用GRPC时出现Run client channel backup poller错误及段错误

该问题本质是Celery默认prefork工作模型与gRPC底层C++实现的兼容性问题：

• Celery prefork模式下，主进程会先加载全部业务代码，再fork出多个子Worker进程执行任务。如果在主进程加载阶段就初始化了gRPC客户端channel，fork后的子进程会继承父进程的内存空间与文件描述符。
• gRPC底层C++库维护的epoll poller文件描述符会在父进程fork完成后被清理，子进程访问这些已失效的文件描述符时就会抛出Bad file descriptor报错。
• 当子进程尝试访问gRPC核心已经释放的内存区域时，就会触发Segmentation fault (core dumped)段错误直接导致Worker崩溃。

• 【推荐】延迟gRPC客户端初始化时机
  不要在Python模块全局作用域初始化gRPC channel和stub，将初始化逻辑绑定到Celery的worker_process_init信号，保证channel在子Worker进程fork完成后才创建，不会和父进程共享无效文件描述符，参考实现：

  from celery.signals import worker_process_init
  import grpc
  from your_proto_package import YourGrpcServiceStub
  
  grpc_stub = None
  
  @worker_process_init.connect
  def init_grpc_client(**kwargs):
      global grpc_stub
      channel = grpc.insecure_channel("your-grpc-server-address:port")
      grpc_stub = YourGrpcServiceStub(channel)
  

• 调整Celery工作池模型
  若业务允许，可将Celery工作池替换为非prefork模型，启动时添加参数--pool=gevent或--pool=solo，从根源避免fork带来的文件描述符继承问题。使用gevent模式时需提前执行gevent猴子补丁，或搭配开启gRPC的fork支持特性使用。
• 开启gRPC官方fork支持
  若使用v1.37.0及以上版本的gRPC库，可在启动Celery进程前设置环境变量GRPC_ENABLE_FORK_SUPPORT=1，gRPC会自动处理fork前后的资源清理逻辑，兼容prefork工作模型。

内容的提问来源于stack exchange，提问作者Minh Sơn Lê