This page contains a list of workarounds for known issues in TeamCity.
- Agent running as Windows Service Limitations
- 'Channel is not opened' error in git repository on bitbucket.org
- Clearing Browser Caсhes
- Logging with Log4J in Your Tests
- Agent Service Can Exit on User Logout under Windows x64
- Failed Build Can be Reported as a Successful One With Maven 2.0.7
- Conflicting Software
- Subversion issues
- NUnit 2.4.6 Performance
- StarTeam Performance
- Perforce 2009.2 Performance on Windows
- Wrong times for build scheduled triggering (Timezone issues)
- Upgrading IntelliJ IDEA May Affect Active Pre-Tested Commits
- Other Java Applications Running on the Same Server
- The Server Does Not Start Claiming the Database is in Use
- Slow download from TeamCity server
- Failure to publish artifacts to server behind IIS reverse proxy
- SSL problems when connecting to HTTPS from TeamCity (handshake alert: unrecognized_name)
Agent running as Windows Service Limitations
When a TeamCity build agent is installed as a Windows service, there may appear various "Permission denied" or "Access denied" errors during the build process, see details below.
The user account used by the service is required to have sufficient permissions to perform the build and manage the service. If you run the TeamCity agent service under the SYSTEM account, do the following:
- Change SYSTEM for a usual user account with necessary permissions granted.
- Restart the service.
Windows service limitations
As a Windows service, the TeamCity agent and the build processes are not able to access network shares and mapped drives.
To overcome these restrictions, run TeamCity agent via console.
Issues with automated GUI and browser testing
These problems include errors running tests headless, issues with the interaction of the TeamCity agent with the Windows desktop, etc.
To resolve/ avoid these:
- Run TeamCity agent via console.
Configure the build agent machine not to launch a screensaver locking the desktop.
- Configure the TeamCity agent to start automatically (e.g. configure an automatic user logon on Windows start and then configure the TeamCity agent start (via agent.bat start) on the user logon).
Early start of the service before other resources are initialized
To handle this, consider using the Automatic (Delayed Start) option of the service settings or configure service dependencies.
'Channel is not opened' error in git repository on bitbucket.org
In July 2016, Bitbucket Cloud has made changes to ssh protocol handling disabling multiplexing for ssh connections. As a result, Git checkout for VCS roots configured with ssh:// protocol in TeamCity fails with "channel is not opened." error (related TeamCity issue).
As a workaround, install an updated version of git-plugin corresponding to your TeamCity version: 9.1.x, 9.0.x or 8.1.x (or 10 EAP) - use artifacts from the latest successful build. To install the plugin, put downloaded jetbrains.git.zip into <TeamCity Data Directory>/plugins and restart the TeamCity server.
Clearing Browser Caсhes
There is a web UI-related issue which some our users have encountered (and it cannot be reproduced on other computers) which is tied with the cached versions of content. If you have come across such problem, make sure your browser does not use cached versions of content by clearing browser caches.
Logging with Log4J in Your Tests
If you use Log4J logging in your tests, in some cases you may miss Log4J output from your logs. In such cases please do the following:
- Use Log4J 1.2.12
For Log4J 1.2.13+, add the
"Follow=true"parameter for console appender, used in Log4J configuration:
Agent Service Can Exit on User Logout under Windows x64
The used version of Java Service Wrapper does not fully support Windows 64 and this causes agent launcher process to be killed on user logout. The agent itself will be function until the next restart (server upgrade or agent properties change).
Failed Build Can be Reported as a Successful One With Maven 2.0.7
This is a known bug in this version of Maven. Consider using any later version.
In case it's not possible you can patch mvn.bat yourself by replacing the fragment at line 148 of
with the following one:
Most common indicators of conflicting software are errors like "Access is denied", "Permission denied" or java.io.FileNotFoundException mentioning the file that is present and is writable by the user the agent/build runs under.
Also, certain software running in background (like antiviruses) can significantly slow down build agent operations like sources checkout, artifact publishing or even build running.
Certain antivirus software like Kaspersky Internet Security can result in Java process crashes or other misbehavior like inability to access files. e.g. see the issue.
ESET antivirus can also slow down Ant/IntelliJ IDEA project builds a great deal (slowing down TCP connections to localhost on agent).
If you run antivirus on the TeamCity server or agent machines and get disk access errors or experience degraded performance, please disable or better completely uninstall the antivirus software before investigating the issue and reporting the issue to JetBrains.
It is recommended to exclude entire TeamCity server home and TeamCity Data Directory from the background checks and perform periodical checks there in the well-known maintenance window so that those do not affect server performance much.
On TeamCity agent, it is recommended to exclude TeamCity agent home from the background checks.
Please disable various indexing services. e.g. there might be problems with Windows Indexing Service. See issue for more details. Windows System Restore Feature might also need disabling.
Please also do not install software with background indexing like WinCVS, TortoiseCVS, TortoiseSVN and other Tortoise* products. This applies to server and also to agents if you use agent-side checkout.
Skype software is known to:
- use port 80 on the system so you might not be able to use TeamCity server using default 80 port.
- corrupt layout of pages displayed in Internet Explorer. Internet Explorer Skype plugin is to blame. (TW-13052).
svn: E175002: Received fatal alert: bad_record_mac
Please add system property -Dsvnkit.http.sslProtocols=SSLv3,TLS on the build server (see Configuring TeamCity Server Startup Properties).
If you use checkout on agent, add this property on build agent as well.
Subversion-related JVM Crashes
If JVM crashes while executing SVN-related code (e.g. under org.tmatesoft.svn package), you can try to disable it by either:
-Dsvnkit.useJNA=falseJVM option to the crashing process (server or agent), or
- Making NTLM support less prioritative by passing
Anyway, upgrading the JVM used to the latest available version is recommended.
NUnit 2.4.6 Performance
Due to an issue in NUnit 2.4.6, its performance may be slower than NUnit 2.4.1. For additional information, please refer to the corresponding issue in our issue tracker: TW-4709
Using StarTeam SDK 9.0 instead of StarTeam SDK 9.3 on the TeamCity server can significantly improve VCS performance when there is a slow connection between TeamCity and StarTeam servers.
Perforce 2009.2 Performance on Windows
If you run Perforce 2009.2 on Windows you may experience significant slow down. This is an issue with P4 server running on Windows. Please refer to corresponding section in Perforce documentation.
Wrong times for build scheduled triggering (Timezone issues)
Please make sure you use the latest JDK available for your platform (e.g. Oracle JDK download).
There were fixes in JDK 1.5 and 1.6 to address various wrong timezone reporting issues.
Upgrading IntelliJ IDEA May Affect Active Pre-Tested Commits
Before you upgrade to IntelliJ IDEA X (or other IntelliJ X platform products) please make sure you do not have active pre-tested commits, otherwise they will not be able to be committed after upgrade.
This is only relevant if you use directory-based IDEA project (project files are stored under
Other Java Applications Running on the Same Server
If other web applications are available via the same hostname, a session cookie conflict can occur. This usually is visible via random user logouts or losing session-level data. (e.g. TW-12654). To resolve this, you can use different host names when accessing the applications.
The Server Does Not Start Claiming the Database is in Use
Only a single TeamCity server can work with one database, which is checked on the TeamCity server start.
"The Database is in Use" error on the start-up is reported in either of the following cases:
- An attempt to start more than one TeamCity server connected to the same database
- A second TeamCity instance detected
- The internal HSQL database is being used by another application
The error is most probably caused by the fact that there is another running TeamCity installation which is connected to the same database. Сheck that the database properties are correct and there is no other TeamCity server using the same database.
In TeamCity 8.0 and earlier, if all the settings are correct, the error can occur when the TeamCity server or the database server has been shut down incorrectly.
The resolution depends on the database type:
- MySQL: restart the MySQL server and then start TeamCity again.
- PostgreSQL, Oracle, MS SQL: kill the connections from the incorrectly shut down TeamCity, and then start TeamCity again.
- Internal database (HSQL): remove the
buildserver.lckfile from the
TeamCity Data Directory\systemdirectory, and then start TeamCity again.
Slow download from TeamCity server
If you experience slow speed when downloading artifacts from TeamCity, try checking the speed on the server machine, downloading from localhost.
If the speed is OK for the localhost, the issue can be in the network configuration or OS/hardware settings when combined with TeamCity(Tomcat) settings.
Please also make sure <TeamCity Home>\conf\server.xml file corresponds to the file included in TeamCity distribution (can be checked in .tar.gz distribution).
If you have the following "Connector" node (ports numbers can be different):
change it to:
and restart TeamCity server.
If this does not help with the download speed, to investigate the case you might need to find an administrator with appropriate network-related issues investigation skills to look into the case.
Failure to publish artifacts to server behind IIS reverse proxy
This problem is only relevant to configurations that involve IIS reverse proxy between build server and agents.
Sometimes a build agent can be found in infinite loop trying to publish build artifacts to server. Build log looks like this:
meanwhile teamcity-agent.log is filled with 404 responses from IIS:
The most common cause for this is maxAllowedContentLength setting (in IIS) either
- is set to too small value
- is left uncofigured and so defaults to 30000000 bytes (<30 Mb)
So any aritfact larger than maxAllowedContentLength is discarded by IIS
Check the settings value and try to rerun your build
SSL problems when connecting to HTTPS from TeamCity (handshake alert: unrecognized_name)
This problem may happen when changing JVM from 1.6 to 1.7 and connecting some incorrectly configured HTTPS servers.
The problem and workaround for it are described in this issue: http://youtrack.jetbrains.com/issue/TW-30210
Please try running with antivirus software uninstalled before reporting the issue to JetBrains. e.g. see the issue.