配置AIRFLOW__SCHEDULER__RUN_DURATION后调度器未按预期自动重启问题问询

• 进程阻塞无法触发退出逻辑：Airflow 2.1.2版本的调度器在遇到异常DAG解析、元数据库死锁、外部依赖（比如对象存储、消息队列）无响应时，可能陷入不可中断的阻塞状态，内部的运行时长计数逻辑停止执行，即便达到设定的3600秒阈值也无法触发自动退出。此时容器内的调度器进程仍然存在，但无心跳输出。
• ECS重启策略不匹配：RUN_DURATION触发的调度器退出为正常退出，退出码为0。如果你的ECS任务重启策略配置为on-failure（仅异常退出时重启），或者ECS健康检查的失败阈值、间隔设置过大，就会出现调度器已经退出但ECS没有重建任务的情况。
• 实际生效配置与环境变量不一致：环境变量的配置可能被更高优先级的配置项覆盖，比如启动命令中通过--runtime-config参数指定的配置、挂载的airflow_local_settings.py覆盖了调度器参数、同路径下的.env文件存在同名配置。需执行airflow config get-value scheduler run_duration命令确认Airflow实际加载的参数值，仅校验操作系统环境变量不足以证明配置生效。
• 版本原生BUG：Airflow 2.1.2存在调度器运行时长计数异常的已知缺陷，当DAG解析队列长期处于满负载状态时，运行时长计数器会暂停更新，导致永远无法触发重启阈值。该问题在2.2.0及以上版本已修复。

不需要。Airflow的配置优先级规则中，环境变量的优先级高于airflow.cfg的配置，只要通过airflow config get-value命令确认实际生效值为3600，两种配置方式的效果完全一致，切换配置方式无法解决当前的重启不生效问题。

临时解决方案建议：在ECS侧新增独立的调度器心跳校验逻辑，定期查询Airflow元数据库中scheduler_job表的最新心跳时间，若心跳间隔超过1.5小时则主动终止当前ECS任务，依靠ECS的自动重建能力恢复调度器，该方案的可靠性远高于依赖Airflow自身的重启逻辑。条件允许的话建议将Airflow升级到2.2.5以上的LTS版本，可同时解决原生调度器宕机和RUN_DURATION不生效的问题。

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