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 不要通過告訴它不要監視失去的程序來終止升級過程？

添加

RemainAfterExit=yes

到該Service節似乎可以解決此問題，而無需更改超時。

記錄在https://www.freedesktop.org/software/systemd/man/systemd.service.html#RemainAfterExit=

自從第一次發布以來已經有一段時間了。

我剛剛對最新版本的 TeamCity 遇到了類似的問題。就我而言，我已將 systemd 配置為以特殊使用者身份執行代理。此使用者似乎沒有執行升級所需的權限。

因此，在代理停止的情況下，我使用 TeamCity 腳本以 root 身份手動重新啟動它。升級成功並啟動了新代理。

但是，此時，代理以 root 身份執行。所以我手動停止它，將建構代理目錄中的權限重置為我的其他使用者（升級後，一些文件屬於 root）並使用 systemctl 重新啟動。這以正確的使用者身份重新啟動了代理。

現在一切似乎都在工作。

引用自：https://serverfault.com/questions/660063