Known Issues

This page contains a list of workarounds for known issues in TeamCity.

Agent running as Windows Service Limitations

When TeamCity build agent is installed as a Windows service, service limitations can affect the builds that the agent is running. At the same time the build can be sensitive to the user it runs under.

Common indicators of the issue are various "Permission denied" or "Access denied" errors during the build process.

The most common service-related issues are:

user the service runs under. The user should have enough permissions to perform the build;
access to network shares and mapped drives. Services have Windows-imposed restrictions to access the resources;
interaction with desktop, headless mode, etc.

Solution

If you run TeamCity agent service under "System", try specifying usual user account with necessary permissions granted and restart the service.

If that does not help, try running TeamCity agent Setting up and Running Additional Build Agents.

For more investigation steps, see Common Problems.

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: <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <param name="Follow" value="true"/> </appender>

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 mvn.bat:

:error set ERROR_CODE=1

with the following one:

:error if "%OS%"=="Windows_NT" @endlocal set ERROR_CODE=1

Conflicting Software

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. Please try running with antivirus software uninstalled before reporting the issue to JetBrains. 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).

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: 1. use port 80 on the system so you might not be able to use TeamCity server using default 80 port. 2. corrupt layout of pages displayed in Internet Explorer. Internet Explorer Skype plugin is to blame. (TW-13052).

Subversion issues

Subversion Repositories With NTLM Authorization

If TeamCity has problems connecting to SVN repository, while using NTLM Authentication, add an option to the Configuring TeamCity Server Startup Properties and to the Configuring Build Agent Startup Properties (if you use agent-side checkout): -Dsvnkit.http.methods=Basic,NTLM See a related forum post on this issue.

TeamCity default setting for svnkit.http.methods property is Digest,Basic,Negotiate,NTLM, so this problem should not arise regularly. However, this can also mean that more secure NTLM authentication is not used by default. To enforce using NTLM, add JVM option -Dsvnkit.http.methods=NTLM,Negotiate,Digest,Basic.

See also a related issue on HTTP Negotiate configuration.

Very slow checkout on agent for Subversion in TeamCity 7.0.x

There are two known cases:

Using 1.7 working copy for checkout - please upgrade to TeamCity 7.0.2, where the problem should be fixed
Using pre-1.7 working copy - please start your build agent under Java 1.7. More details in this issue

svn: E175002: Received fatal alert: bad_record_mac

Please add system property -Dsvnkit.http.sslProtocols=SSLv3 on the build server (see Configuring TeamCity Server Startup Properties). If you use checkout on agent, add this property Configuring Build Agent Startup Properties as well.

If JVM crashes while executing SVN-related code (e.g. under org.tmatesoft.svn package), you can try to disable it by either:

Passing -Dsvnkit.useJNA=false JVM option to the crashing process (server or agent), or
Making NTLM support less prioritative by passing -Dsvnkit.http.methods=Basic,Digest,NTLM JVM option.

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

StarTeam Performance

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 .idea directory).

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.

Server Does Not Start Claiming the Database is in Use

Only a single TeamCity server can work with one database. This is checked on the TeamCity server start and a startup error can be reported:

The most probable reason of this message is that there is another running TeamCity installation which is connected to the same database. Please double check that the Setting up an External Database are correct and no other TeamCity server uses the same database.

If all settings are correct, the error can occur when TeamCity server or the database server has been shut down incorrectly. The resolution depends on the database type:

MySQL: the only way is to restart the MySQL server and then start TeamCity again. PostgreSQL, Oracle, MS SQL: kill connections from the incorrectly shut down TeamCity, and then start TeamCity again. Internal database (HSQL): remove the 'buildserver.lck' file in the TeamCity Data Directory\system directory, and then start TeamCity again.

Last modified: 20 April 2023