☰

升级时 Teamcity Build Agent 被 systemd 杀死

tag-icon • tag-icon service centos7 systemd teamcity
升级时 Teamcity Build Agent 被 systemd 杀死

在我们的 centos 系统上，我们已将 teamcity 代理配置为 systemd 服务。除了代理执行升级时，该服务运行良好。然后在执行升级时它会被终止。我猜这是因为 systemd 监视创建的进程，当主进程存在以让第二个进程执行升级时，systemd 认为这是一个丢失的进程并在大约一分钟后将其终止。

我猜这个假设得到了证实，因为当我直接启动 teamcity 代理时，升级没有任何问题。

这是该服务的配置：

[Unit]
Description=teamcity agent - local
Requires=network.target
After=network.target

[Service]
Type=forking
PIDFile=/home/teamcityagent/logs/buildAgent.pid
WorkingDirectory=/home/teamcityagent
User=teamcityagent
Group=teamcityagent
ExecStart=/home/teamcityagent/bin/agent.sh start
ExecStop=/home/teamcityagent/bin/agent.sh stop
TimeoutStartSec=900
TimeoutStopSec=60

[Install]
WantedBy=multi-user.target

到目前为止，我已尝试将超时时间更改为 900 秒并注释掉 PIDFile。但没有任何帮助。

有没有办法告诉 systemd 不要监视丢失的进程，从而不要终止升级过程？

答案1

添加

RemainAfterExit=yes

该Service节似乎可以解决这个问题，而不需要改变超时。

记录于https://www.freedesktop.org/software/systemd/man/systemd.service.html#RemainAfterExit=

答案2

从这篇文章首次发布以来已经有一段时间了。

我刚刚在使用最新版本的 TeamCity 时遇到了类似的问题。就我而言，我已将 systemd 配置为以特殊用户身份运行代理。此用户似乎没有执行升级所需的权限。

因此，在代理停止后，我使用 TeamCity 脚本以 root 身份手动重新启动它。升级成功，新代理已启动。

但是，此时代理以 root 身份运行。因此我手动停止它，将构建代理目录中的权限重置为我的其他用户（升级后，某些文件属于 root），然后使用 systemctl 重新启动。这会以正确的用户身份重新启动代理。

现在一切似乎都正常了。

相关内容