TeamCity 2019.1ヘルプ

既知の問題

このページには、TeamCityの既知の課題に対する回避策のリストが含まれています。

Windowsサービスとして実行されているエージェント

TeamCityビルドエージェントをWindowsサービスとしてインストールすると、ビルドプロセス中にさまざまな "Permission denied"または "Access denied"エラーが表示されることがあります。詳細は以下を参照してください。

セキュリティ関連の課題

サービスで使用されるユーザーアカウントには、ビルドを実行してサービスを管理するための十分なアクセス許可が必要です。SYSTEMアカウントでTeamCityエージェントサービスを実行している場合は、次の手順を実行します。

  1. 必要な権限が付与された通常のユーザーアカウント用の変更 SYSTEM。

  2. サービスを再開してください。

Windowsサービスの制限

Windowsサービスとして、TeamCityエージェントとビルドプロセスはネットワーク共有とマップされたドライブにアクセスできません。

これらの制限を克服するには、コンソールから TeamCityエージェントを実行してください。

自動GUIおよびブラウザテストの課題

これらの課題には、ヘッドレステストの実行エラー、TeamCityエージェントとWindowsデスクトップとの相互作用の課題などが含まれます。

これらを解決/回避するには

  1. コンソールから TeamCityエージェントを実行します。

  2. デスクトップをロックするスクリーンセーバーを起動しないようにビルドエージェントマシンを設定します。

  3. TeamCityエージェントを自動的に開始するように構成します(たとえば、Windows開始時に自動ユーザーログオンを構成し、ユーザーログオン時にTeamCityエージェントの開始を(agent.batを介して)構成します)。

グラフィカルテストの場合、ビルドエージェントをサービスとして開始することはできません。ユーザーの自動ログオン後1分遅れてビルドエージェントの起動を構成することをお勧めします。タスクスケジューラで bin\agent.bat start コマンドを使用し、そこで遅延を構成します。

自動GUIテストの実行とRDPの使用

RDPはセッションのためにマシンのビデオカードからのものをオーバーライドするそれ自身のビデオドライバを使用します。セッションをコンソールにリダイレクトすると、Windowsのグラフィカルドライバがアンロードされます。これは、テストの前にビルド構成に次の手順を追加することで実行できます(以下の例はPowerShell用ですが、他の言語(DOS、Python)も使用できます)。

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

"quser [current username]"には、ユーザーがそのマシンに接続しているすべての接続が一覧表示されます(コンソールまたはグラフィカル)。
rdp-tcp#* としてリストされているものは、"tscon [connection id] /dest:console"を使用してコンソールにリダイレクトできるリモートデスクトップ接続です。

との課題: 純セレン

TeamCityエージェントがWindowsサービスとして起動され、.NETアプリケーションの自動テストがSelenium WebDriverを使用する場合、ブラウザドライバの制限によりテストが失敗することがあります。解決策として、エージェントを手動で起動することを検討してください。

他のリソースが初期化される前のサービスの早期開始

これを処理するには、サービス設定の自動 (遅れたスタート)オプションの使用を検討するか、サービスの依存関係(英語)を構成します。

詳しい調査手順については、よくある問題のページを参照してください。

java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できません

TeamCityサーバーがSUSE®Linux Enterprise(またはsystemd Daemonを使用)で実行されている場合、java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できませんは、cgroupプロセス番号コントローラー(英語)機能がプロセスの数(英語)とcgroup内のスレッドの量をデフォルトで512に制限するために発生する可能性があります。

制限を大きくすると(TeamCityサーバーの4096など)、課題は解決します。

この外部投稿(英語)も参照してください。

ブラウザキャッシュの消去

一部のユーザーが遭遇した(および他のコンピューターで再現できない)Web UI関連の課題は、コンテンツのキャッシュバージョンに関連しています。このような課題に遭遇した場合は、ブラウザーのキャッシュをクリアして、ブラウザー(英語)がコンテンツのキャッシュバージョンを使用しないようにしてください。

テストでLog4jを使ってロギングする

テストでLog4jロギングを使用していると、場合によってはLog4jの出力がログから失われることがあります。そのような場合は、次の手順に従ってください。

  • Log4j 1.2.12を使用

  • Log4j 1.2.13+の場合、Log4j構成で使用されるコンソールアペンダに "Follow=true" パラメータを追加します。

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

エージェントサービスは、Windows x64でのユーザーログアウトで終了できます。

使用されているバージョンのJavaサービスラッパー(英語)はWindows 64を完全にはサポートしていないため、ユーザーのログアウト時にエージェントランチャープロセスが強制終了されます。エージェント自体は、次回の再起動(サーバーのアップグレードまたはエージェントのプロパティーの変更)まで機能します。

失敗したビルドはMaven 2.0.7で成功したと報告されることがある

これはMavenのこのバージョンの既知のバグです。それ以降のバージョンの使用を検討してください。
それが不可能な場合は、mvn.batの148行目のフラグメントを置き換えることによって mvn.bat にパッチをあてることができます。

:error set ERROR_CODE=1

次のように:

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

矛盾するソフトウェア

競合するソフトウェアの最も一般的な指標は、"Access is denied"、"Permission denied"、または存在し、エージェント/ビルドが実行されているユーザーによって書き込み可能なファイルについてメンションしているjava.io.FileNotFoundExceptionなどのエラーです。また、バックグラウンドで実行されている特定のソフトウェア(アンチウイルスなど)は、ソースのチェックアウト、アーティファクトの公開、またはビルドの実行など、ビルドエージェントの操作を大幅に遅くする可能性があります。

カスペルスキーインターネットセキュリティなどの特定のウイルス対策ソフトウェアは、Javaプロセスのクラッシュや、ファイルにアクセスできないなどのその他の不正動作を引き起こす可能性があります。たとえば、課題(英語)を参照してください。

ESETアンチウイルスはAnt / IntelliJ IDEAプロジェクトを遅くすることもできます(エージェント上のlocalhostへのTCP接続を遅くする)。

TeamCityサーバーまたはエージェントマシンでウイルス対策を実行し、ディスクアクセスエラーが発生したり、パフォーマンスが低下したりする場合は、課題を調査してJetBrainsに報告する前に、ウイルス対策ソフトウェアを無効にするか完全にアンインストールします。

TeamCityサーバーホーム全体とTeamCityデータディレクトリーをバックグラウンドチェックから除外し、既知のメンテナンスウィンドウで定期的なチェックを実行して、サーバーのパフォーマンスに大きな影響を与えないようにすることをお勧めします。TeamCityエージェントでは、バックグラウンドチェックからTeamCityエージェントホームを除外することをお勧めします。

Windowsインデックスサービスに課題がある可能性があるため、さまざまなインデックスサービスを無効にします。詳細については、関連する課題(英語)を参照してください。Windowsシステムの復元機能も無効にする必要がある場合があります。

WinCVS、TortoiseCVS、TortoiseSVN、およびその他のTortoise *製品のようなバックグラウンドインデックス付きのソフトウェアをインストールしないでください。これはサーバーに適用され、エージェント側のチェックアウトを使用する場合はエージェントにも適用されます。

Skypeソフトウェアは、以下のことが知られています。

  • システムのポート80を使用すると、デフォルトのポート80ではTeamCityサーバーを利用できない可能性があります。

  • Internet Explorerに表示されるページのレイアウトが正しくありません。Internet ExplorerのSkypeプラグインは非難することです。(TW-13052(英語)

Subversionの課題

SVN: E175002: 致命的なアラートを受信: bad_record_mac

ビルドサーバーにシステムプロパティー -Dsvnkit.http.sslProtocols=SSLv3,TLS を追加します(TeamCityサーバー起動プロパティーの設定を参照)。
エージェントでチェックアウトを使用する場合は、このプロパティーをビルドエージェントにも追加します。

Subversion関連のJVMクラッシュ

SVN関連のコード(org.tmatesoft.svnパッケージなど)の実行中にJVMがクラッシュした場合は、次のいずれかの方法で無効にすることができます。

  • クラッシュしたプロセスに -Dsvnkit.useJNA=false JVMオプションを渡す (サーバーまたはエージェント)

  • -Dsvnkit.http.methods=Basic,Digest,NTLM JVMオプションを渡すことにより、NTLMサポートの優先順位を下げます。
    使用されているJVMを最新の利用可能なバージョン(英語)にアップグレードすることをお勧めします。

NUnit 2.4.6のパフォーマンス

NUnit 2.4.6の課題により、そのパフォーマンスはNUnit 2.4.1より遅くなるかもしれません。追加情報については、当社の課題トラッカーの該当する課題を参照してください。TW-4709(英語)

StarTeamの性能

TeamCityサーバーでStarTeam SDK 9.3の代わりにStarTeam SDK 9.0を使用すると、TeamCityサーバーとStarTeamサーバー間の接続が遅い場合に、VCSのパフォーマンスが大幅に向上します。

WindowsでのPerforce 2009.2パフォーマンス

WindowsでPerforce 2009.2を実行すると、大幅なスローダウンが発生する場合があります。これは、Windowsで実行されているP4サーバーの課題です。Perforceのドキュメントの対応するセクション(英語)を参照してください。

ビルドスケジュールされたトリガーの間違った時間 (タイムゾーンの課題)

プラットフォームで利用可能な最新のJava 8インストール用アップデート(たとえばOpenZDK 8 by AdoptOpenJDK(英語))を使うようにしてください。

IntelliJ IDEAをアップグレードすると、事前にテストされたアクティブなコミットに影響を与える可能性があります

IntelliJ IDEA X(または他のIntelliJ Xプラットフォーム製品)にアップグレードする前に、アクティブな事前テスト済みコミットがないことを確認してください。そうしないと、アップグレード後にコミットできなくなります。これは、ディレクトリーベースのIDEAプロジェクトを使用する場合にのみ関係します(プロジェクトファイルは .idea ディレクトリーに格納されています)。

同じサーバー上で実行されている他のJavaアプリケーション

同じホスト名で他のWebアプリケーションが利用可能な場合は、セッションCookieの競合が発生する可能性があります。これは通常、ランダムなユーザーのログアウトやセッションレベルのデータの消失によって見えます。(例:TW-12654(英語))これを解決するために、アプリケーションにアクセスするときに異なるホスト名を使用できます。

データベースが使用中であると主張してサーバーが起動しない

1つのTeamCityサーバーのみが1つのデータベースを処理できます。これはTeamCityサーバーの起動時にチェックされます。

次のいずれかの場合に、起動時の "The Database is in Use"エラーが報告されます。

  • 同じデータベースに接続されている複数のTeamCityサーバーを始動しようとしました

  • 2番目のTeamCityインスタンスが検出された

  • 内部HSQLデータベースが別のアプリケーションによって使用されています

このエラーは、おそらく同じデータベースに接続されている別の実行中のTeamCityインストールがあるという事実によって引き起こされます。データベースのプロパティーが正しいこと、および同じデータベースを使用しているTeamCityサーバーが他にないことを確認してください。

TeamCity 8.0以前、すべての設定が正しい場合、TeamCityサーバーまたはデータベースサーバーが誤ってシャットダウンされたときにエラーが発生する可能性があります。解決方法はデータベースの種類によって異なります。

  • MySQL : MySQLサーバーを再起動してからTeamCityを再起動します。

  • PostgreSQLOracleMS SQL:誤ってシャットダウンしたTeamCityから接続を強制終了してから、再度TeamCityを起動します。

  • 内部データベース(HSQL):<TeamCityホーム> \ systemディレクトリーから buildserver.lck ファイルを削除してから、TeamCityをもう一度起動します。

TeamCityサーバーからのダウンロードが遅い

TeamCityからアーティファクトをダウンロードするときに速度が遅い場合は、localhostからダウンロードしてサーバーマシンで速度を確認してください。localhostの速度が課題ない場合、TeamCity(Tomcat)設定と組み合わせると、課題はネットワーク構成またはOS /ハードウェア設定にある可能性があります。

<TeamCityホーム> \ 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サーバーを再起動します。

これがダウンロード速度を助けない場合、ケースを調査するために、ケースを調査するために適切なネットワーク関連課題調査スキルを持つ管理者を見つける必要があるかもしれません。

IISリバースプロキシの背後にあるサーバーにアーティファクトを公開できない

この問題は、ビルドサーバーとエージェント間のIISリバースプロキシを含む構成にのみ関係します。ビルドアーティファクトをサーバーに公開しようとしているビルドエージェントが無限ループで見つかることがあります。ビルドログは次のようになります。

[11:15:05]Publishing artifacts [11:15:05][Publishing artifacts] Collecting files to publish: [toZip/** => artifact.zip] [11:15:06][Publishing artifacts] Creating archive artifact.zip (9s) [11:15:06][Creating archive artifact.zip] Creating C:\BuildAgent\temp\buildTmp\ZipPreprocessor2847146024236637664\artifact.zip [11:15:15][Creating archive artifact.zip] Archive was created, file size 32142324 bytes [11:15:15][Publishing artifacts] Sending toZip/** [11:15:25][Publishing artifacts] Sending toZip/** [11:15:39][Publishing artifacts] Sending toZip/** [11:15:48][Publishing artifacts] Sending toZip/** [11:16:01][Publishing artifacts] Sending toZip/** [11:16:16][Publishing artifacts] Sending toZip/**

一方、teamcity-agent.logはIISからの404の応答でいっぱいになります。

[2012-08-01 12:04:55,514] WARN - jetbrains.buildServer.AGENT - <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;}

これの最も一般的な原因は maxAllowedContentLength 設定(IISの場合)です

  • 小さすぎる、または

  • 未設定のままで、デフォルトは30000000バイト (<30 Mb)

そのため、maxAllowedContentLength より大きいアーティファクトはIISによって破棄されます。設定値を確認して、ビルドを再実行してください。

プレリリースパッケージはTeamCity NuGetフィードに表示されません

問題 : プレリリースパッケージはTeamCity NuGetフィードに表示されません。

原因 : パッケージバージョンが必要な形式(英語)に違反している場合、NuGetクライアントバージョン3より前はプレリリースパッケージのリストに失敗します。

ソリューション : 必要な形式(英語)に違反するバージョンのビルドアーティファクトを削除します。

TeamCity NuGetフィードでパッケージのインデックス作成が遅い

問題 : TeamCityサーバーホストマシンをTeamCity 2017.1ビルドメタデータに移動またはアップグレードした後でリセットできます。

原因 : TeamCity NuGetフィードはビルドメタデータに依存しており、パッケージの再インデックス作成はパッケージの数とTeamCityサーバーのアイドル時間によっては多くの時間がかかります。

ソリューション : メタデータの再インデックス作成を高速化するには、以下の内部プロパティーを指定します。

teamcity.buildIndexer.indexPackSize=1000 teamcity.buildIndexer.packSleepDurationMs=10

メタデータのインデックス作成の進行状況を確認するには、teamcity-server.logファイルで次のような行を探します。

INFO - .index.BuildIndexer (metadata) - Enqueued next 100 builds for indexing, builds left: 7064, last build id: 8142

インデックスの再作成が完了したら、これらの内部プロパティーを削除します。

TeamCityからHTTPSに接続する際のSSLの問題(ハンドシェイクアラート): 認識されていない名前)

この課題は、JVMを1.6から1.7に変更し、いくつかの誤って構成されたHTTPSサーバーを接続するときに発生する可能性があります。この課題とその回避策については、この課題(英語)で説明します。

MS SQL ServerとTeamCityを接続するSSLの問題

MS SQL Serverは常にjdbcクライアント(TeamCityアプリケーション)とサーバーとの間にSSL接続を確立するため、接続の問題が発生する可能性があります。(SQL例外:Connection reset)。

影響を受けるMS SQLのバージョン

下記のバージョンより前のバージョン

  • SQL Server2012製品版以降

  • SQL Server2008Service Pack 3累積アップデート4

  • SQL Server 2008 R2 Service Pack 1累積アップデート6

  • SQL Server 2008R2サービスパック2

原因 : この問題は、このセキュリティの脆弱性(英語)に対処するJava 1.6の更新が原因です。

ソリューション : Microsoft SQL Serverアップグレードをお勧めします。

回避策 : 何らかの理由でMicrosoft SQL Serverのアップグレードが不可能な場合は、データベース接続をSSLまたはTLSで暗号化したまま、古いバージョンのMicrosoft SQL Serverを使用するようにTeamCityを設定できます。

  • AES_128_CBC3DES_EDE_CBCなどのブロック暗号を引き続き使用しますが、-Djsse.enableCBCProtection=false Javaコマンドラインオプション( ここで説明するように TEAMCITY_SERVER_OPTS 環境変数に追加できます)でCBC保護を無効にします。jsse.enableCBCProtection JavaシステムプロパティーはすべてのOpenJDK 8バージョンでも使用できます。IBM J9 8.0.0 SR1(英語)以降TeamCityMicrosoft SQL Serverの間の安全な接続は安定していますが、それでもBEASTとも呼ばれるCVE-2011-3389(英語)に対して脆弱です。

  • RC4_128などのストリーム暗号(BEASTの影響を受けにくい)にフォールバックします。これにより、接続がCVE-2015-2808(英語)に対して脆弱になります。

JetBrainsに課題を報告する前に、ウイルス対策ソフトウェアをアンインストールして実行してください。たとえば、課題(英語)を参照してください。

Windows Dockerコンテナー

TeamCity Dockerコンテナーイメージに共通の問題。

  • KB4340917(英語)を使用したWindows 10バージョン1803以降、コンテナーからローカルホストへのポートマッピングを使用することが可能です。以前のWindowsバージョンでは、このマシンに関連付けられている非ローカルホストのIPアドレスに対して機能します。マシンのホスト名を使用して実行中のアプリケーションにアクセスするか、ipconfig コマンドを使用してIPアドレスを決定できます。実際には動作しますが、netstat -an コマンドではポートがどのIPアドレスでも開いていることが示されない場合があります。これはWindows上のDockerの既知の問題でもあります。

  • Windows 10では、コンテナーごとに割り当てられるメモリはデフォルトで1GBです。この値を増やすには、以下のメモリオプションを使用します。

    docker run ... -m 2GB -e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:ReservedCodeCacheSize=350m"
  • Windows 10ではコンテナーはHyper-V経由で動作し、ネットワークや他のサブシステムで問題が発生する可能性があります。これらの問題を診断するには、次のPowerShellスクリプトを実行してください。

    Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression
  • WindowsのDockerイメージからTeamCityサーバーを起動するときは、必ずボリュームとして使用されているディレクトリーに対して Authenticated Users フルコントロールを付与してください: 関連号を見る(英語)

  • ボリュームとしてコンテナーホストにマップされたディレクトリー C:/BuildAgent/work でWindows Dockerコンテナーを起動すると、Git for Windowsは次のエラーで失敗します:「無効なパス '/ ContainerMappedDirectories':そのようなファイルまたはディレクトリーはありません」。回避策は、C:/BuildAgent/work をボリュームとして追加しないことです。

スクリプト出力を分析するには、次のドキュメント(英語)を参照してください。コンテナーネットワークサブシステムに問題があることが示されている場合は、クリーンアップスクリプト(英語)を使用してリセットしてください。

Windows用Dockerのトラブルシューティングに関する詳細は、Docker(英語)およびマイクロソフト(英語)のドキュメントにあります。

WindowsにインストールされたDockerサーバーOSに関する情報がエージェントにない

Windows 10では、DockerサーバーはHyper-Vサービスに依存しており、起動にはかなりの時間がかかります。この課題を解決するには、TCZildAgent WindowsサービスをDocker for Windowsサービス(デフォルトでは "com.docker.service" )に依存するように設定します。

Windows上のLinux Dockerコンテナー

TeamCity 2017.2以降、DockerラッパーはWindowsベースのコンテナーが起動されたときにWindows上で動作します。

LinuxコンテナーがWindowsマシンで起動されている場合、TeamCityは「WindowsでのLinux Dockerコンテナーの起動はサポートされていません。この問題を回避するには、 teamcity.agent.jvm.os.name にWindows エージェントの要件は含まれません」というエラーメッセージを表示します。

DockerラッパーがWindowsプラットフォームでLinuxコンテナーを実行しているときにユースケースをサポートする必要がある場合は、TW-51820(英語)で/ commentに投票してください。

Windowsコンテナーの現地時間の問題

Windows Dockerコンテナーを使用する場合、コンテナー(英語)のシステム時刻がホストマシンの時刻と同期しなくなると、Windowsコンテナーの時刻が正しく(英語)なくなる課題があります。応答時間が重要な統合(OAuthトークンなど)で課題が発生する可能性があります。

この問題を解決するには、ホストマシンをWindows Server 2019 / Windows 10 1809にアップグレードし、TeamCity dockerイメージWindowsコンテナー1809と互換性(英語)があります。を使用してください。

コンテナーの起動時に「アクセスが拒否されました」または「パスへのアクセスが拒否されました」問題

Dockerは、プロセス分離を使用してWindowsコンテナーを開始するときに、Dockerボリュームを含むディレクトリーへの書き込みアクセス権がないWindowsユーザーアカウントを使用します。この場合、次のエラーが原因でビルドエージェントの起動に失敗することがあります。

Move-Item : Access to the path is denied. ... CategoryInfo : PermissionDenied: (<path to properties file>:FileInfo) [Move-Item], UnauthorizedAccessException FullyQualifiedErrorId : MoveFileInfoItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.MoveItemCommand

この課題を解決するには、%PROGRAMDATA%docker\volumes ディレクトリーの「Authenticated Users」グループに「フルコントロール」権限を付与します。