async: 0 与 poll: 0 组合可实现无等待、不轮询的真正异步托管，使长时编译任务在所有节点并行启动且不阻塞ansible控制流；需配合nohup/&启动、register捕获pid、wait_for验证产物等机制确保可观测与可控。
直接用 async: 0 配合 poll: 0，就能让 Ansible 启动编译任务后立即返回、不等待、不轮询，把控制权交还给你，同时确保所有节点上的编译进程真正并行启动——这是处理数小时级批量编译最可靠的做法。
为什么不能依赖默认同步模式
默认 fork=5 + 同步执行，意味着 100 台机器要分 20 批、串行跑完一轮编译；每批必须等全部 5 台编译结束才进下一批。不仅总耗时翻倍（实际是单台编译时间 × 批次数），还会阻塞终端、无法做其他事。更关键的是：编译本身是长时后台进程，Ansible 不该卡在“等它输出”上。
async 和 poll 的真实分工
– async 是最大容忍运行时长（秒），超时则标记为 failed；设为 0 表示“无限等待”，即不设硬性截止，任其跑满几小时；
– poll 是轮询间隔（秒），设为 0 表示“完全不轮询”，Ansible 发起任务即认为“已提交”，立刻释放 shell 并继续后续 task（比如发通知、记录 job_id）；
– 二者组合为 async: 0, poll: 0，才是对真正长任务的无侵入式托管。
如何安全启动并追踪编译进程
仅靠 async/poll 启动还不够，需配套机制确保可观察、可管理：
- 用 command 或 shell 模块启动编译，并加上
&或nohup，例如：nohup make -j$(nproc) > /var/log/compile.log 2>&1 & - 用 register 捕获 stdout 中的 PID 或日志路径，再通过 set_fact 存为 host_var，供后续 wait_for 或 debug 调用
- 后续加一个独立 task，用 wait_for 检查编译产物（如二进制文件是否存在、大小是否非零）、或用 uri 模块轮询内部状态接口，实现“异步发起 + 同步收尾”
- 配合 ignore_errors: yes 和 failed_when 精确控制失败条件（比如只当 log 出现 “ERROR: out of memory” 才报错）
避免常见陷阱
– 不要给编译任务设小 async 值（如 600），否则还没编译完就被强制 kill；
– 不要用 poll: 10 类轮询方式盯数小时任务，既浪费控制机资源，又可能因网络抖动漏判完成；
– 别在 playbook 中混用同步任务与 async:0 任务后立刻读取结果——前者会等，后者已脱管，顺序不等于执行时序；
– 确保目标机 ulimit、/tmp 空间、GCC 版本一致，这些不会被 async/poll 掩盖，却是编译失败的主因。
