Common Problems

Build fails or behaves differently in TeamCity but not locally

If the build fails or otherwise misbehave in TeamCity but you believe it should not, please:

• check that the build runs fine on the same machine as TeamCity agent and under the same user that the agent is running, with the same environment variables and the same working directory.
• if TeamCity build agent is installed as a Windows service, try running TeamCity agent via console. See also Windows Service limitations.

If this fixes the issue, you can try to figure out why running under the service is a problem for the build. Most often this is service-specific and does not relate to TeamCity directly. Also, you can setup TeamCity agent to be run from console all the time (e.g. configure automatic user logon and run the agent on user logon).

The following approach can be used for this test:
For a configured build in TeamCity which is failing:

• run the build and see it misbehaving
• disable the agent so that no other builds run on it. This can be done while the build is still in progress
• log in to the agent machine using the same user as TeamCity agent runs under
• stop the agent
• in a command console, cd to the checkout directory of the build in question (the directory can be looked up in the beginning of the build log in TeamCity)
• run the build with a command line as you would do on a developer machine. This is runner-dependent. (for some runners you can look up the command line used by TeamCity in the build log)
• if the build fails - investigate the reason as the issue is probably not TeamCity specific and should be investigated on the machine.
• if it runs OK, continue
• in the same console window cd to <TeamCity agent home>\bin and start TeamCity agent from there with agent start command
• ensure the runner settings in TeamCity are appropriate and should generate the same command line as you used manually
• run the build in TeamCity selecting the agent in Run custom build dialog
• when finished, enable the agent

You can also find the command that TeamCity used to launch the build in logs\teamcity-agent.log agent log file.

If the build succeeds from console but still fails in TeamCity, please create a new issue in our tracker detailing the case. Please attach the build log, all agent logs covering the build, the command you used in console to run the build and the full console output of the build.

Agent does not upgrade with "Agent has unregistered (will upgrade)"

This means the agent is downloading the new agent version and should become connected shortly. The time necessary to upgrade mostly depends on the network link between the agent and the server. After downloading the files upgrade can take 1-3 minutes.

If the agent stays in the state for more then 10 minutes and you have fast network connection between the agent and the server, please look into agent logs.
If you cannot find the cause of the delayed agent upgrade in the logs, contact us and attach the agent logs and the server logs.

Artifacts of a build are not cleaned

If you encounter a case when artifacts of a build are not cleaned, please check:

• the cleanup rules of the build configuration in question, artifacts cleanup section
• presence of the icon "This build is used by other builds" in the build history line (prior to Pin action/icon on Build History)
• build's Dependencies tab, "Delivered Artifacts" section. For every using build configuration, check whether "Prevent dependency artifacts clean-up" is turned ON (this is default value). If it does, then the build's artifacts are not cleaned because of the setting.
  Read more on cleanup settings.

"out of memory" error with internal (HSQLDB) database

If while TeamCity server statup you encounter errors like:

• "error in script file line: ... out of memory"
• "java.sql.SQLException: out of memory"

Try increasing server memory.
If this does not help, most probably this means that you have encountered internal database corruption. You can try to deal with corruption based on notes on HSQLDB documentation.

A way to attempt a manual database restore:

• stop the TeamCity server
• remove <TeamCity Data Directory>/system/buildserver.data file and replace it with zero-size file of the same name. Please backup the removed file beforehand.
• start the TeamCity server

However, if the database does not recover automatically, chances that it can be fixed manually are minimal.

Unfortunately, internal (HSQL) database is not stable enough for production use and we highly recommend using external database for TeamCity non-evaluation usage.
If you encountered database corruption, you can restore last good backup or drop builds history and users, but preserve the settings, see Migrating to an External Database#Switching to Another Database.