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起動時に自動ユーザーログオンを設定し、次にユーザーログオン時にagent.bat startを介してTeamCityエージェント起動を設定します)。

    グラフィカルテストの場合は、ビルドエージェントをサービスとして起動することはできません。ユーザーの自動ログオンから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デーモンを使用して)実行されている場合、java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できませんcgroupプロセス番号コントローラー(英語)機能が原因で、デフォルトでプロセス数(英語)とcgroup内のスレッド数が512に制限されることがあります。

Increasing the limit (e.g. to 4096) on the TeamCity server should solve the issue.

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

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

キャッシュされたバージョンのコンテンツに関連している(そしてそれは他のコンピューターで再現することができない)何人かの私達のユーザーが遭遇した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 ""=="Windows_NT" @endlocal set ERROR_CODE=1

矛盾するソフトウェア

競合するソフトウェアの最も一般的な指標は、"Access is denied"、"Permission denied"、または存在し、エージェント/ビルドが実行されているユーザーによって書き込み可能なファイルについてメンションしている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ソフトウェアは、以下のことが知られています。

  • システムのポート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より遅くなるかもしれません。追加情報については、当社のissue trackerの該当する課題を参照してください。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 Server 2012 Production version and later

  • SQL Server 2008 Service Pack 3 Cumulative Update 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コンテナーイメージに共通の問題

Windows Dockerコンテナー

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

  • 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が次のエラーで失敗します: "Invalid path '/ContainerMappedDirectories': No such file or directory"。回避策は、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トークン)。

To address it, upgrade your host machine to Windows Server 2019 / Windows 10 1809 and use TeamCity docker images compatible with Windows containers 1809(英語)

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

Dockerがプロセス分離を使用してWindowsコンテナーを起動しているときは、dockerボリュームのあるディレクトリーへの書き込みアクセス権がない SERVICE ユーザーアカウントを使用しています。これを解決するには、SERVICE ユーザーに %PROGRAMDATA%docker\volumes ディレクトリーに対する「フルコントロール」権限を付与します。