已知问题

在 JDK 8u242+ 下运行的 TeamCity 版本最高可达 2019.2.1，可以报告 java.lang.NoClassDefFoundError：无法初始化类 XXX 错误，例如，在 Git 操作或 Windows 域认证操作上。

在 TeamCity 2019.2.2 发布之前，建议您使用 Java 8u232 版本进行 TeamCity 服务器。

当 TeamCity 构建代理安装为 Windows 服务时，在构建过程中可能出现各种"权限被拒绝"或"访问被拒绝"的错误，具体详见以下内容。

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

如果您的 TeamCity 服务器运行在 SUSE® Linux Enterprise（或使用 systemd Daemon），则 java.lang.OutOfMemoryError：无法创建新的本地线程错误 可能由 cgroup 进程数控制器 功能引起，该功能默认将 cgroup 的进程和线程数量限制为 512。

在 TeamCity 服务器上增加限制（例如，增至 4096）应该可以解决此问题。

也可以参阅这个 外部发布。

一些用户遇到了与网络界面相关的问题（其他计算机无法复现该问题），这与缓存版本的内容有关。 如果您遇到了此类问题，请确保您的浏览器未使用内容的缓存版本，方法是 清除浏览器缓存。

如果您在测试中使用 Log4j 记录，那么在某些情况下，您可能会错过来自您日志的 Log4j 输出。 在这种情况下，请按照以下步骤操作：

• 使用 Log4j 1.2.12

• 对于 Log4j 1.2.13\+，请为在 Log4j 配置中使用的控制台追加器添加 遵循=true 参数：

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

使用的 Java Service Wrapper 版本并未完全支持 Windows 64 ，这导致用户注销时，代理启动器进程被终止。 代理本身将一直运行，直到下一次重启（服务器升级或代理属性更改）。

这是 Maven 当前版本中的一个已知错误。 请考虑使用任何较新的版本。
如果无法做到，您可以通过替换 mvn.bat 中第 148 行的片段来自行修补 mvn.bat。

:error
set ERROR_CODE=1

与以下内容一致：

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

最常见的冲突软件指示符是像“拒绝访问”，“权限被拒绝”或 java.io.FileNotFoundException这样的错误，其中提到了存在且可以由代理/构建运行的用户写入的文件。 另外，某些在后台运行的软件（如杀毒软件）可能会大大降低构建代理操作的速度，例如源代码签出、构件发布甚至构建运行。

某些防病毒软件，如 Kaspersky Internet Security，可能会导致 Java 进程崩溃或产生其他异常行为，例如无法访问文件。 例如，查看 此问题。

ESET 防病毒软件也可能大大降低 Ant / IntelliJ IDEA 项目构建的速度（减慢代理上 localhost 的 TCP 连接）。

如果您在 TeamCity 服务器或代理机器上运行防病毒软件，并且出现磁盘访问错误或性能下降，您可能会考虑在调查问题和向 JetBrains 报告之前暂时禁用防病毒软件。 请注意，禁用防病毒软件可能会使您的设置更容易受到潜在的外部攻击，所以在做此操作之前，请确保您已采取适当的安全措施。

我们建议在后台检查中排除整个 TeamCity 服务器主目录和 TeamCity 数据目录 ，并在公认的维护窗口中定期进行检查，以便这些操作不会过多地影响服务器性能。 在 TeamCity 代理上，建议从背景检查中排除 TeamCity 代理安装目录。

可能存在与 Windows 索引服务相关的问题，因此请禁用各种索引服务。 请参阅 相关问题 获取更多详情。 可能还需要禁用 Windows 系统还原功能。

不要安装带有后台索引功能的软件，如 WinCVS 、 TortoiseCVS 、 TortoiseSVN 、以及其他 Tortoise* 产品。 这适用于服务器，如果您使用代理端检出，也适用于代理。

众所周知，Skype 软件会破坏在 Internet Explorer 中显示的页面布局。 （TW-13052）。

由于 NUnit 2.4.6 中的一个问题，它的性能可能会比 NUnit 2.4.1 慢。 如需更多信息，请参考我们问题跟踪器中对应的问题： TW-4709

在 TeamCity 服务器上使用 StarTeam SDK 9.0 替代 StarTeam SDK 9.3 可以在 TeamCity 和 StarTeam 服务器之间的连接速度较慢时，显著提高 VCS 的性能。

如果您在 Windows 上运行 Perforce 2009.2 ，您可能会经历显著的速度减慢。 这是一个在 Windows 上运行的 P4 服务器出现的问题。 参考 Perforce 文档中相应的 部分。

请确保您使用针对您的平台的最新 Java 8 安装更新（例如，由 Amazon Corretto 提供的 OpenJDK 8）。

在您升级到 IntelliJ IDEA X （或其他 IntelliJ X 平台产品）之前，确保您没有活动的预测试提交，否则升级后将无法提交。 如果您使用基于目录的 IDEA 项目（项目文件存储在 .idea 目录下），这只是相关的。

如果同一主机名下还有其他可用的网络应用，可能会出现会话cookie冲突。 这通常表现为随机用户登出或丢失会话级数据。 （例如， TW-12654）。 为了解决这个问题，您可以在访问应用程序时使用不同的主机名。

只有一个 TeamCity 服务器可以与一个数据库一起工作，这在 TeamCity 服务器启动时进行检查。

在以下任一情况下，启动时会报告 "数据库正在使用中 " 错误：

• 尝试启动多个连接到同一数据库的 TeamCity 服务器

• 检测到第二个 TeamCity 实例

• 内部的 HSQL 数据库正在被另一款应用程序使用

错误很可能是由于另一个正在运行的 TeamCity 安装连接到了同一数据库所导致的。 请检查 数据库属性是否正确，确保没有其他的 TeamCity 服务器使用相同的数据库。

如果您在从 TeamCity 下载构件时遇到下载速度慢的问题，尝试在服务器机器上检查速度，从 localhost 下载。 如果 localhost 的速度可以，那么问题可能出在网络配置或者操作系统 / 硬件设置上，当它们与 TeamCity（Tomcat）设置结合时。

请确保 \< TeamCity Home \>\conf\server.xml 文件与 TeamCity 分发包中包含的文件相对应（可在 .tar.gz 分发包中检查）。 如果您有以下的 "Connector" 节点（端口号可能会有所不同）：

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

将其更改为：

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

并重新启动 TeamCity 服务器。

如果这无法帮助提高下载速度，为了调查此问题，您可能需要找具有相关网络问题调查技能的管理员来查看此问题。

当从 1.6 切换到 1.7 的 JVM 并连接一些配置不正确的 HTTPS 服务器时，可能会出现这个问题。 问题和解决方法在 此问题 中进行了描述。

当在已经安装了不同版本 Java 的代理上通过 Windows 代理安装程序 安装一个 TeamCity 代理时，" 配置构建代理属性" 安装窗口可能会显示扭曲。

此问题已在 TeamCity 2019.1.5 中修复.

要在不升级到 2019.1.5 的情况下解决此问题，请在将新代理安装到同一目录之前卸载先前安装的代理版本。
要卸载代理，请在 代理主目录 中调用 Uninstall.exe ，清除所有 "移除..." 复选框以保留代理日志和配置，然后单击 卸载。 成功卸载后，您可以通过代理安装程序继续安装新的代理版本。

自动的 TeamCity 更新可能无法将新版本号写入相关的 Windows 注册表键。 这会导致标准 Windows 添加或删除程序 应用程序显示初始 TeamCity 安装的版本，而这一版本在更新后不会发生变化。

要手动更新注册表键并设置正确的版本，请按照 TeamCity 管理 | 更新 页面上的说明，运行随您的 TeamCity 安装附带的 PowerShell 脚本：

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

与 TeamCity Docker 容器镜像相关的常见问题。

• 自从 Windows 10 版本 1803 配合 KB4340917 ，就可以从容器中使用端口映射到 localhost。 对于较早的 Windows 版本，它适用于与此计算机相关的非 localhost IP 地址，您可以通过主机名访问正在运行的应用程序或通过 ipconfig 命令确定 IP 地址。 请注意， netstat -an 命令可能无法显示端口在任何 IP 地址上是否打开，尽管事实上它可以工作。 这也是 Docker 在 Windows 上的一个已知问题。

• 在 Windows 10 上，默认为每个容器分配 1GB 内存。 要增加此值，请使用以下内存选项：

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

• 在 Windows 10 中，容器通过 Hyper-V 运行，可能会遇到网络和其他子系统的问题。 要诊断这些问题，请执行以下的 PowerShell 脚本：

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

• 当从 Windows Docker 镜像启动 TeamCity 服务器时，请确保向“ 经过认证的用户 ”授予对用作卷的目录的 完全控制权限。 请参阅相关问题。

• 当使用目录 C:/BuildAgent/work 作为映射到容器主机的卷来启动 Windows Docker 容器时，Git for Windows 会出现以下错误：" 无效路径 '/ContainerMappedDirectories'：没有此类文件或目录"。 解决方法是不要将 C:/BuildAgent/work 添加为一个卷。

要分析脚本输出，请参阅以下 文档。 如果显示出容器网络子系统存在问题，尝试使用 clean-up scripts 进行重置。

有关 Windows 的 Docker 故障排除的更多细节在 Docker 和 Microsoft 的文档中都有提供。

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

如果您为 Xcode 使用自定义输出目录，请注意，在升级到 Xcode 10 时，使用 Xcode 项目构建运行器的 TeamCity 构建可能会失败，并出现以下错误：" 无法删除 \<目录\>，因为它不是由构建系统创建的，也不是派生数据的子文件夹。"

这是由以下 Xcode 10 已知问题引起的：
当在一个使用了自定义构建位置（位于派生数据目录外）的项目上执行 xcodebuild clean ，并且该项目具有在 Xcode 10 之前生成的旧构建产品时，Xcode 可能会报告一个错误，表示它不会删除未由新构建系统创建的目录。 (40427159)
请参阅 Xcode 文档 以获取详细信息。

为了解决这个问题，我们建议您使用 Xcode 11。 为了解决 Xcode 10 中的这个问题，您可以手动清理输出目录，或尝试通过向命令行参数传递 -UseNewBuildSystem=NO 来使用前一种构建系统。

由于最近对 SameSite cookie 支持的更新， 项目 弹出菜单可能不会在一些最新的网络浏览器中显示 跨服务器项目 （参见 Chrome 平台的 更多详细信息）。

如果您无法访问跨服务器 项目 菜单，您可以尝试通过更改浏览器设置来暂时解决此问题：

• 在 Google Chrome 中，打开 chrome://flags 页面并禁用 "SameSite by default cookies" 选项。

• 在 Mozilla Firefox 中，打开 about:config 页面并禁用 network.cookie.sameSite.laxByDefault 选项。

• 在 Safari 中，转到 首选项 | 隐私 并禁用 "防止跨站点跟踪" 选项。

note

禁用此设置将降低您浏览器的整体安全性。 仅在必要时使用此解决方法。 我们强烈建议您等待下一个版本的 TeamCity 解决此问题。

这个问题将在 TeamCity 2020.1.5 更新中得到解决。 请查看 相关问题 以获取更多细节。

早期版本的 PowerShell 运行器不支持传递多行参数。 自2020.1.4版本起，您可以通过设置 teamcity.powershell.arguments.multiline=true 配置参数 来启用此支持。

加载 VCS 更改时出错可能与在 MySQL 中启用的基于光标的流式处理有关。这种情况可能在 TeamCity 服务器启动时发生。 为了防止此错误，尝试在 database.properties 中将 connectionProperties.useCursorFetch 属性设置为 false ，然后重新启动服务器。
更多详细信息，请查看 此问题。

• 在某些情况下，TeamCity 可能会在 JetBrains Space 中的旧开放合并请求以及 Bitbucket Cloud 中的拉取请求上启动构建。 此问题可以通过以下步骤复现：

  1. 创建一个新的 VCS 根，以连接到一个有开放合并请求的仓库。 保留默认分支规格说明。

  2. 使用此 VCS 根目录和 VCS 触发器创建一个构建配置。

  3. 从 VCS 根中删除分支规格。

  4. 将 Pull Requests 构建功能添加到构建配置中。

  5. 禁用 Pull Requests 功能，然后再次启用它。

  请查看 相关问题 以获取更多细节。

• 拉取请求 构建功能可能会在 JetBrains Space 中的合并请求时间线中发布错误的构建步骤编号。 请查看 相关问题。

由于 Git 2.35.2 中引入了 更严格的存储库所有权检查 ，更新 TeamCity 服务器的 Git 到此版本或更高版本可能会导致故障（例如，出现 "fatal: could not read from remote repository" 消息）。 尝试以下解决方案作为暂时的办法：

• 如果您的 TeamCity 服务器运行在 Linux 上，请确保 <TeamCity 数据目录>/system/caches/git 目录的卷是在 TeamCity 用于访问此目录的同一用户下挂载的。

• 如果您在通过 Windows Docker 镜像安装或更新的 TeamCity 服务器 上遇到相关问题，请禁用 native Git 以强制 TeamCity 服务器使用 JGit 代替。

这些问题涉及在 TeamCity 服务器上使用原生的 Git 来检出资源，该应用自 2022.04 版本起就生效了。

普通 ZIP 格式支持大小最多为 2 ^{32 字节（4 GB）的存档。 由于构建可能会生成超过此值的工件，TeamCity 使用支持最大为 2}64 字节（16 exabytes）存档的 ZIP64 格式压缩工件。

如果您用来解压 TeamCity 构建工件的工具不支持 ZIP64（例如，您可能会看到头错误警告），请向项目（要么是 <Root project>，要么是生成不受支持的档案的特定项目）添加以下 配置参数：

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