6

On our centos system we have configured a teamcity agent as a systemd service. The service works fine except when the agent performs an upgrade. Then it gets killed while performing the upgrade. I guess this is due to the fact, that systemd watches the created processes and when the main process exists to let a second process perform an upgrade systemd decides this is a lost process and kills it after about a minute.

I guess this assumption gets validated by the fact that when i directly start the teamcity agent the upgrade works without a problem.

This is the configuration of the service:

[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

So far I have tried to change the timeout to 900secs and commented out the PIDFile. Nothing helped.

Is there a way to tell systemd to not kill the upgrade process by telling it not to watch for lost processes?

5

Adding

RemainAfterExit=yes

to the Service stanza appears to fix this without needing to change timeouts.

Documented at https://www.freedesktop.org/software/systemd/man/systemd.service.html#RemainAfterExit=

| improve this answer | |
0

It's been a while since this was first posted.

I just had a similar problem with the latest version of TeamCity. In my case, I had configured systemd to run the agent as a special user. This user doesn't seem to have the required permissions to perform the upgrade.

So, with the agent stopped, I restarted it manually as root with the TeamCity scripts. The upgrade succeeded and the new agent was started.

However, at that point, the agent was running as root. So I stopped it manually, reset permissions in the build agent directory to my other user (after the upgrade, some files belonged to root) and restarted using systemctl. This restarted the agent as the proper user.

All seems to be working now.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.