Airflow 2.2.2 webserver Worker因signal 11终止如何调试？

• 版本兼容性排查 #

  该问题大概率出现在C扩展依赖的版本不兼容场景，优先检查以下依赖：
  • Postgres驱动psycopg2：如果安装的是源码编译版本，确认其编译依赖的系统libpq库版本和运行环境一致，建议直接替换为psycopg2-binary官方预编译包测试
  • 检查Airflow 2.2.2依赖的gunicorn、SQLAlchemy版本是否和现有应用的依赖冲突，执行pip check可以快速识别依赖不匹配问题

• 单进程Debug模式复现 #

  直接执行airflow webserver --debug启动单进程调试模式，该模式不会fork子worker，所有逻辑在主进程执行，如果触发段错误会直接输出完整的错误栈，比多worker模式更容易定位问题

• 核心转储分析 #

  段错误场景下核心转储是最直接的定位手段：
  1. 启动服务前执行ulimit -c unlimited放开核心转储文件大小限制
  2. 启动Airflow触发worker崩溃，会在工作目录生成core.<pid>格式的转储文件
  3. 用gdb分析调用栈：gdb python3 core.<pid>，进入gdb后执行bt命令打印完整调用栈，即可定位到触发段错误的具体库和代码位置

• 最小环境验证 #

  新建一个干净的Python 3.9虚拟环境，只安装Airflow 2.2.2和对应的Postgres依赖，用相同的配置启动webserver：
  • 如果干净环境可以正常启动，说明是现有应用的其他依赖和Airflow依赖冲突，逐一对比两个环境的依赖包版本即可定位冲突包
  • 如果干净环境也复现崩溃，说明是系统级依赖或者Airflow本身的版本问题

• 场景替换验证 #

  • 替换worker类型：启动时添加参数--worker-class gevent使用gevent worker，验证是否还会触发段错误，如果替换后正常，说明是sync worker和底层依赖的兼容性问题
  • 替换元数据库：临时将Airflow元数据库换成SQLite，若启动正常则问题出在Postgres连接逻辑，可进一步排查数据库SSL配置、网络策略等相关项

• 系统层面排查 #

  执行dmesg | grep -E 'segfault|airflow|gunicorn'查看系统日志有没有附加的错误信息，同时检查是否开启了SELinux、AppArmor等安全模块，临时关闭后验证是否恢复

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