设置execution_timeout后仍触发AirflowTaskTimeout的DAG任务故障求助

1. 优先修正代码中的传参错误 #

你当前定义linkedin_jobs_task的代码存在Airflow新手易踩的典型坑：
python_callable=linkedin_jobs.scrap_jobs()
这里在函数名后加了括号，等于在DAG文件被scheduler加载解析的阶段，就直接执行了scrap_jobs的爬取逻辑，根本不是等到任务触发时才运行代码。

• 这个执行阶段没有挂载任务级别的超时监控钩子，不管你把execution_timeout设成多少，都不会对这个阶段运行的代码产生管控效果。一旦爬取过程碰到异常，会直接导致DAG文件解析失败，scheduler端呈现的现象就是任务运行几十秒后异常崩溃，和你描述的“运行37秒就崩”的表现完全匹配。
• 正确写法是去掉函数后的括号，把函数引用本身传给python_callable，也就是python_callable=linkedin_jobs.scrap_jobs。如果需要给爬取函数传参，要通过op_args、op_kwargs字段传递，绝对不能在DAG定义阶段就直接调用爬取函数。

2. 排除非Airflow机制触发的崩溃 #

你遇到的崩溃时长（约37秒）远低于自己配置的300秒超时阈值，说明崩溃根本不是Airflow的超时规则触发的，要重点排查运行环境的问题：

• 树莓派的硬件内存普遍偏低，跑网站爬取时如果一次性拉取大量页面响应、没有做流式内容处理，很容易触发Linux内核的OOM killer机制，直接杀掉内存占用最高的Airflow任务进程。这类进程被杀的耗时通常就在几十秒量级，和你描述的崩溃时长高度匹配。可以执行dmesg | grep -i oom 查看内核日志，确认是否是内存保护机制终止了任务，也可以用htop在任务运行时实时观察内存占用变化。
• 不要只看Airflow UI上截断的日志，要找到树莓派上worker本地存储的完整任务日志，定位崩溃前最后一行的实际报错信息，不要默认把崩溃原因归错到超时配置上。

3. 理清容易混淆的配置逻辑 #

• 你在DAG层级设置的dagrun_timeout=timedelta(seconds=300)是整个DAG实例从启动到结束的总超时限制，和单任务的execution_timeout是完全独立的两个配置，触发逻辑、生效范围都不一样，不要混淆。
• 任务级别的execution_timeout配置优先级高于default_args里的全局配置，你在任务参数里传的300秒超时配置本身是会正常生效的，不需要调整这块逻辑。
• 确认任务运行环境中，lib目录的导入路径是可被Python正常识别的，避免因为模块导入失败导致任务刚启动就抛异常。

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