Known Issues

TeamCity versions up to 2019.2.1 running under JDK 8u242+ can report java.lang.NoClassDefFoundError: Could not initialize class XXX errors, for example, on Git operations or Windows domain authentication operations.

Until TeamCity 2019.2.2 is released, it is recommended to use Java 8u232 version for TeamCity server.

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.

$sessionInfo=((quser $env:USERNAME | select -Skip 1) -split '\s+')
if ($sessionInfo[1] -like "rdp-tcp*") { tscon $sessionInfo[2] /dest:console }

If your TeamCity server is running on SUSE® Linux Enterprise (or using systemd Daemon), the java.lang.OutOfMemoryError: unable to create new native thread error may be caused by the cgroup process number controller feature limiting the number of processes and the amount of threads in a cgroup to 512 by default.

Increasing the limit (for example, to 4096) on the TeamCity server should solve the issue.

See also this external posting.

There is a web UI-related issue which some users have encountered (and it cannot be reproduced on other computers) which is tied to 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.

If you use Log4j logging in your tests, in some cases you may miss the Log4j output from your logs. In such cases do the following:

• Use Log4j 1.2.12

• For Log4j 1.2.13\+, add the Follow=true parameter for the console appender used in Log4j configuration:

  <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
    <param name="Follow" value="true"/>
  </appender>

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

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

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 the background (like antivirus) can significantly slow down such build agent operations as 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. For example, see this issue.

ESET antivirus can also slow down Ant/IntelliJ IDEA project builds a great deal (slowing down TCP connections to localhost on an agent).

If you run antivirus on the TeamCity server or agent machines and get disk access errors or experience degraded performance, you may consider temporarily disabling the antivirus software before investigating the issue and reporting it to JetBrains. Note that disabling the antivirus can make your setup more vulnerable to potential external attacks — ensure you take proper security measures before doing this.

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.

There might be problems with the Windows Indexing Service, so disable various indexing services. See the related issue for more details. Windows System Restore Feature might also need disabling.

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 corrupt layout of pages displayed in Internet Explorer. (TW-13052).

Due to an issue in NUnit 2.4.6, its performance may be slower than NUnit 2.4.1. For additional information, 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.

If you run Perforce 2009.2 on Windows you may experience significant slow down. This is an issue with P4 server running on Windows. Refer to corresponding section in Perforce documentation.

Make sure you use the latest update for Java 8 installation available for your platform (e.g. OpenJDK 8 by Amazon Corretto).

Before you upgrade to IntelliJ IDEA X (or other IntelliJ X platform products), 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).

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.

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.

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.

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):

<Connector port="8111" protocol="HTTP/1.1"
               connectionTimeout="60000"
               redirectPort="8543"
               useBodyEncodingForURI="true"
    />

change it to:

<Connector port="8111" protocol="org.apache.coyote.http11.Http11NioProtocol"
                connectionTimeout="60000"
                redirectPort="8543"
                useBodyEncodingForURI="true"
                socket.txBufSize="64000"
                socket.rxBufSize="64000"
                tcpNoDelay="1"
                                />

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.

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.

When installing a TeamCity agent via a Windows agent installer on top of the already installed agent with a different version of Java, the " Configure Build Agent Properties " installation window might appear distorted.

This issue has been fixed in TeamCity 2019.1.5.

To work around this issue without upgrading to 2019.1.5, uninstall the previously installed agent version before installing a new agent into the same directory.
To uninstall the agent, invoke Uninstall.exe in the Agent Home Directory, clear all the " Remove... " checkboxes to keep the agent logs and configuration, and click Uninstall. After the successful uninstallation, you can proceed with installing the new agent version via the agent installer.

Automatic TeamCity updates may fail to write new version numbers to the related Windows registry key. This causes the standard Windows Add or Remove Programs application to show the version of the initial TeamCity installation that never changes after updates.

To manually update the registry key and set a correct version, follow the instructions on the TeamCity Administration | Updates page to run a PowerShell script shipped with your TeamCity installation:

runas /user: Administrator "powershell -File C:\TeamCity\bin\update-registry-version.ps1"

Problems common to TeamCity Docker container images.

• Since Windows 10 version 1803 with KB4340917 it's possible to use port mapping from containers to localhost. For previous Windows versions it works for the non\-localhost IP address associated with this machine and you can access a running application via the machine's hostname or determine the IP address via the ipconfig command. Note that the netstat -an command may not show that the port is open on any IP address, while in fact it can work. This is also a known problem of Docker on Windows.

• On Windows 10, the memory allocated per container is 1GB by default. To increase this value, use the following memory options:

  docker run ... -m 6GB --cpus=4 -e TEAMCITY_SERVER_MEM_OPTS="-Xmx3g -XX:ReservedCodeCacheSize=640m"

• On Windows 10 containers work via Hyper-V and may experience problems with network and other subsystems. To diagnose these problems, execute the following PowerShell script:

  Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression

• When starting a TeamCity server from a Windows Docker image, make sure to grant " Authenticated Users " the Full Control over the directories used as volumes. See the related issue.

• When starting a Windows Docker container with the directory C:/BuildAgent/work mapped as a volume to the container host, Git for Windows fails with a following error: " Invalid path '/ContainerMappedDirectories': No such file or directory ". The workaround is not to add C:/BuildAgent/work as a volume.

To analyze the script output, refer to the following documents. If it shows that there are problems with the container network subsystem, try resetting it using the clean-up scripts.

More details on troubleshooting Docker for Windows are available in the Docker and Microsoft documentation.

docker run --memory="6g" --cpus=4 -e TEAMCITY_SERVER_MEM_OPTS="-Xmx3g -XX:MaxPermSize=270m -XX:ReservedCodeCacheSize=640m" --name teamcity-server-instance
    -v <path-to-data-directory>:C:/ProgramData/JetBrains/TeamCity
    -v <path-to-logs-directory>:C:/TeamCity/logs
    -v <path-to-temp-directory>:C:/TeamCity/temp
    -p <port-on-host>:8111 jetbrains/teamcity-server

If you use a custom output directory for Xcode, note that on upgrading to Xcode 10, TeamCity builds with the Xcode Project build runner might fail with the error: " Could not delete \<directory\> because it was not created by the build system and it is not a subfolder of derived data."

This is caused by the following Xcode 10 known issue:
When performing xcodebuild clean on a project that uses a customized build location outside the derived data directory, and that has older build products produced prior to Xcode 10, Xcode might report an error indicating that it won't delete directories not created by the new build system. (40427159)
See Xcode documentation for details.

To resolve this issue, we suggest that you use Xcode 11 instead. To work around this issue in Xcode 10, you can either clean the output directory manually or try using the previous build system by passing -UseNewBuildSystem=NO to command line parameters.

Due to the recent updates in the SameSite cookie support, the Projects pop-up menu may not display cross-server projects in some latest web browsers (see more details for Chrome Platform).

If you cannot access the cross-server Projects menu, you can try to temporarily work around this issue by changing your browser settings:

• In Google Chrome, open the chrome://flags page and disable the " SameSite by default cookies " option.

• In Mozilla Firefox, open the about:config page and disable the network.cookie.sameSite.laxByDefault option.

• In Safari, go to Preferences | Privacy and disable the " Prevent cross-site tracking " option.

note

By disabling this setting, you reduce the overall security of your browser. Use this workaround only if necessary. We highly recommend that you wait until this issue is fixed in the next version of TeamCity.

This problem will be resolved in the TeamCity 2020.1.5 update. See the related issue for more details.

Earlier versions of the PowerShell runner don't support passing multiline arguments. Since version 2020.1.4, you can enable this support by setting the teamcity.powershell.arguments.multiline=true configuration parameter.

Error while loading VCS changes on the TeamCity server startup might be associated with the enabled cursor-based streaming in MySQL. To prevent this error, try setting the connectionProperties.useCursorFetch property to false in database.properties and restart the server.
See this issue for more details.

• In some cases, TeamCity could start builds on old open merge requests in JetBrains Space and pull requests in Bitbucket Cloud. This is reproduced with the following sequence of steps:

  1. Create a new VCS root that connects to a repository with open merge requests. Leave the default branch specification.

  2. Create a build configuration with this VCS root and a VCS trigger.

  3. Remove the branch specification from the VCS root.

  4. Add the Pull Requests build feature to the build configuration.

  5. Disable the Pull Requests feature and then enable it again.

  See the related issue for more details.

• The Pull Requests build feature could post a wrong build step number to the merge request timeline in JetBrains Space. See the related issue.

Due to more strict repository ownership checks introduced in Git 2.35.2, updating the TeamCity server's Git to this or a newer version may result in malfunctions (for instance, the "fatal: could not read from remote repository" message). Try the following workarounds as temporary solutions:

• If your TeamCity server runs on Linux, ensure the volume with the <TeamCity data dir>/system/caches/git directory is mounted under the same user that TeamCity utilizes to access this directory.

• If you experience related issues on a TeamCity Server installed or updated via a Windows Docker image, disable the native Git to force the TeamCity server to use JGit instead.

These issues concern the use of native Git for checking out sources to the TeamCity server, effective since version 2022.04.

The regular ZIP format supports archives up to 2^{32 bytes (4 GB) in size. Since builds can produce artifacts that exceed this value, TeamCity compresses artifacts with the ZIP64 format that supports archives as large as 2}64 bytes (16 exabytes).

If tools that you utilize to unzip TeamCity build artifacts do not support ZIP64 (for example, you may observe header error warnings), add the following configuration parameters to a project (either a <Root project> or a specific project that produces unsupported archives):

teamcity.internal.artifacts.useZip64=Never
teamcity.internal.artifacts.useByteChannelForZip=false