Azure Pipelines启动后台Python脚本异常求助

我之前也碰到过一模一样的情况，Azure Pipelines的任务会严格监控子进程的STDIO流，而且当任务结束时会清理所有关联的子进程——这就是你遇到两个问题的核心原因：要么STDIO没完全关闭导致超时报错，要么脚本跟着流水线任务一起终止。

问题根源拆解 #

• 直接用python3 forecasts.py &：脚本的标准输入/输出/错误流还和流水线任务的终端绑定着，流水线会一直等这些流关闭，超过10秒就触发那个STDIO超时报错；同时任务结束时，父进程会给子进程发SIGHUP信号，脚本直接被终止。
• 只用nohup却没做额外处理：nohup确实能忽略SIGHUP信号，但如果进程还属于任务的进程组，流水线结束时还是可能被回收；而且没把输出完全重定向的话，STDIO流还是会和任务关联，照样触发超时。

可行解决方案 #

方案1：临时启动（适合测试场景）

用nohup结合输出重定向+disown，彻底脱离任务的STDIO和进程组：

nohup python3 /home/ubuntu/$(Build.Repository.Name)/s/forecasts.py > /dev/null 2>&1 & disown

• > /dev/null 2>&1：把标准输出和错误都丢去/dev/null，彻底断开和任务STDIO的关联
• disown：把后台进程从当前shell的作业列表里移除，流水线任务结束后就不会影响它

或者用setsid创建全新会话，让进程完全独立：

setsid python3 /home/ubuntu/$(Build.Repository.Name)/s/forecasts.py > /dev/null 2>&1 &

方案2：注册系统服务（推荐生产环境）

把脚本做成systemd服务，这是最可靠的方式——脚本作为独立系统服务运行，和流水线完全解耦，还能实现开机自启、故障自动重启：

1. 在你的代码仓库里新增一个forecasts.service文件，内容如下：

[Unit]
Description=Forecasts Scheduler Script
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/$(Build.Repository.Name)/s
ExecStart=/usr/bin/python3 /home/ubuntu/$(Build.Repository.Name)/s/forecasts.py
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

2. 修改Azure Pipelines的Bash任务，替换原来的启动命令为：

# 把服务文件复制到systemd目录
sudo cp /home/ubuntu/$(Build.Repository.Name)/s/forecasts.service /etc/systemd/system/
# 重新加载systemd配置
sudo systemctl daemon-reload
# 启动服务并设置开机自启
sudo systemctl enable --now forecasts.service

这样就算流水线任务结束，服务也会持续运行；如果脚本意外崩溃，systemd还会自动重启它，稳定性拉满。

验证方法 #

流水线结束后，登录虚拟机执行ps aux | grep forecasts.py（方案1）或者systemctl status forecasts.service（方案2），就能确认脚本是否在正常运行了。

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