一般的な問題
ほとんどのユーザーの問題は、次のトピックに関連しています。 問題を報告する前に、これらのヘルプページのいずれかに解決策がすでに含まれているかどうかを確認してください。
ローカルではビルドが動作するが TeamCity では失敗または誤動作する
TeamCity でビルドが失敗したり想定外の動作をしたりする場合、まず、その問題が TeamCity に関連しているかどうかを確認してください。
これを行うには、次の手順に従います。
コマンドプロンプトからタスクを実行する方法を見つけます。 TeamCity エージェントマシン上で、TeamCity エージェントの実行ユーザーと同じユーザー、エージェントが受け取る環境と同じ環境で動作することを確認してください。 必要に応じて、別のユーザーで TeamCity エージェントを実行するか、その環境を調整してください。
コマンドが正常に実行されたら、カスタムスクリプト設定で コマンドラインランナーを使用して、TeamCity ビルドで同じコマンドを構成します。
それがうまくいく場合は、それが該当すると思われる場合は別のランナーを試してください。
アプローチの詳細は以下のとおりです。
TeamCity エージェントと同じマシン上で、エージェントが実行されているのと同じユーザー、同じ環境変数、同じ作業ディレクトリ、同じアーキテクチャ (32/64 ビット) のコマンドラインで実行したときに、コマンドプロンプトからビルドが正常に実行されることを確認してください。
TeamCity ビルドエージェントがサービスとして実行されている場合 (たとえば Windows サービスとしてインストールされている場合)、管理者権限を持つ通常のユーザーで、 コマンドラインから TeamCity エージェントを実行してみてください。 Windows サービスの制限も参照してください。
これで問題が解決した場合は、サービスで実行することがビルドに問題となる理由を突き止めることができます。 ほとんどの場合、これはサービス固有のもので、TeamCity とは直接関係ありません。 また、TeamCity エージェントを常にコンソールから実行するように設定することもできます (たとえば、自動ユーザーログオンを 構成し、ユーザーログオン時にエージェントを実行します)。
コマンドラインからビルドを実行するために使用できる詳細な手順は次のとおりです。
TeamCity で構成済みのビルドが失敗していると想定して、次を実行してください:
TeamCity でビルドを実行し、誤動作することを確認する
他のビルドが実行されないようにエージェントを無効にします。 これはビルドがまだ進行中の間に行うことができます
TeamCity エージェントを実行しているユーザーと同じユーザーでエージェントマシンにログインする (マシンのプロセスリストで正しいユーザーを確認してください)
エージェントを停止する
コマンドラインコンソールで、
cdを対象のビルドのチェックアウトディレクトリに移動します (ディレクトリは TeamCity のビルドログの先頭で確認できます)開発者マシンで行うのと同じように、コマンドラインでビルドを実行します。 これはランナーに依存します。 (一部のランナーでは、TeamCity が使用したコマンドラインをビルドログで確認できます。TeamCity が使用したコマンドラインについては
logs\teamcity-agent.logファイルも参照してください)ビルドが失敗した場合 — 問題はおそらく TeamCity 関連ではなくマシン上で調査する必要があるため、原因を調査してください。
正常に実行された場合は、続行します
同じコンソールウィンドウで
cdして<TeamCity エージェントホーム>/バイナリディレクトリに移動し、そこからエージェントの起動コマンドで TeamCity エージェントを起動しますTeamCity のランナー設定が適切であり、手動で使用したものと同じコマンドラインを生成することを確認してください。 例: カスタムスクリプトオプションと
.shまたは.batファイルに保存してコマンドプロンプトから実行できる同じコマンドで コマンドラインビルドステップを使用するRun custom build ダイアログでエージェントを選択して、TeamCity でビルドを実行する
終了したら、エージェントを有効にします
コンソールからはビルドが成功するのに TeamCity ではまだ失敗する場合は、TeamCity のコマンドラインランナーを使用して、コンソールと同じコマンドを起動します。
TeamCity でまだ動作が異なる場合は、おそらく環境またはツールの問題です。
コマンドラインランナーは機能するが、オプションがすべて同じであるのに専用ランナーが機能しない場合は、ケースの詳細を示す新しい問題を トラッカー(英語)に作成します。 すべてのビルドステップ設定、ビルドログ、ビルドをカバーするすべてのエージェントログ、ビルドを実行するためにコンソールで使用したコマンド、ビルドの完全なコンソール出力を添付してください。
TeamCity でビルドが遅い
ビルドが遅い場合は、まずビルドログをチェックして、時間のかかる操作があるかどうか、時間がプロセス全体に分散しているかどうかを確認します。 遅いビルドと速いビルドのビルドログを比較して、違いが何であるかを把握できます。 上記で説明したように同じマシンのコンソールからビルドを実行し、コンソールから実行したビルドと TeamCity でのビルドに違いがあるかどうかを確認することもできます。
処理の遅延がすべての操作に及んでいる場合は、ビルド中にエージェントマシンのリソース（CPU、ディスク、メモリ、ネットワーク）を分析し、いずれかのリソースにボトルネックが発生していないかを確認する必要があります。 パフォーマンスモニタータブでは、ビルドで使用されている CPU、メモリ、ディスク I/O の量と、どのステージで使用されているかを確認できます。
ビルドプロセスがハングアップしている場合は、実行中のビルド結果ページにあるスレッドダンプを表示リンクをクリックすると、その理由がわかります。
時間のかかる操作があり、それが TeamCity 関連のもの (実際のビルドプロセスの開始前または終了後) である場合は、TeamCity エージェントとサーバーを分析する必要があります (ログとスレッドダンプ)。
この問題について お問い合わせになる場合は、目に見える影響を説明し、調査プロセスの詳細を記載し、ビルドログ、完全なエージェントログ、収集したその他のデータを添付してください。
起動済みのビルドエージェントがサーバーでビルドを実行できない
インストール後、または TeamCity サーバーのアップグレード/プラグインインストール後にエージェントを初めて起動する場合、エージェントがサーバーから更新をダウンロードして自動アップグレードするため、時間がかかることがあります。
通常、エージェントは、エージェント / サーバーのネットワーク接続速度にもよりますが、1 〜 10 分で接続されるはずです。
その時間内にエージェントが接続されない場合は、エージェントの名前（conf\buildAgent.properties ファイルで構成されている）を確認し、 エージェント ページのタブを確認してください。
エージェントが Connected にある — エージェントはビルドを実行する準備ができています
エージェントは切断中です — エージェントはサーバーに接続されていましたが、切断されました。 表の「非アクティブの理由」を確認してください。 理由が「エージェントが登録解除されました (アップグレードします)」の場合は、さらに数分間待ちます
エージェントが Unauthorized にある — 初めてサーバーに接続したすべてのエージェントは、サーバー管理者による承認が必要です
エージェントが 10 分以上状態を維持し、エージェントとサーバー間のネットワーク接続が速い場合は、以下の手順を実行します。
関連するエージェントマシンを調べて、エージェントプロセスが実行されていること、および
conf\buildAgent.properties内のサーバー URLが正しいこと（およびサーバーがその URL からマシンから到達可能であること）を確認します。関連する環境 要件がすべて満たされていることを確認します。
エージェントログ (
teamcity-agent.log、ランチャー.ログ。、upgrade.log) で関連するメッセージやエラーを確認します。エージェント名または IP が記載されたメッセージやエラーがないか、 サーバーログ (
teamcity-サーバー.ログ) を確認します。
エージェントのアップグレードが遅延した原因をログで見つけられない場合は、 お問い合わせのうえ、完全なエージェントログとサーバーログを提供してください。 エージェントマシン上のエージェントプロセス（java プロセス）の状態を必ず確認 / 含めてください。
ビルドのアーティファクトがクリーンアップされない
サーバーのクリーンアッププロセスによって削除されるはずのアーティファクトが保持されている場合は、以下を確認してください。
ビルド構成のクリーンアップ規則、アーティファクトセクション
ビルド履歴行に「このビルドは他のビルドで使用されています」というアイコンが表示されている (ビルド履歴のピンアクション / アイコンの前)
build の Dependencies タブの " アーティファクトのアーティファクト " のセクション。 すべてのビルド構成について、「依存関係のあるアーティファクトのクリーンアップを防止する」がオンになっているかどうかを確認します（これはデフォルト値です）。 そうであれば、その設定のためにビルドのアーティファクトは消去されません。
クリーンアップ設定の詳細を参照してください。
データベース関連の問題
"out of memory" エラー (内部 (HSQLDB) データベース)
TeamCity サーバーの起動中に "error in script file line: ... out of memory"、 "java.sql.SQLException: out of memory" のようなエラーが発生した場合は、次を実行してください:
サーバーメモリを増やしてみてください。 それでも問題が解決しない場合は、 内部データベースの破損 している可能性があります。 HSQLDB ドキュメントに基づく メモ(英語)を使用して、この破損に対処してみてください。
これは手動でデータベースを復元する方法です。
TeamCity サーバーを停止する
<TeamCity データディレクトリ>/system/buildserver.dataファイルをバックアップする<TeamCity データディレクトリ>/system/buildserver.dataファイルを削除し、同じ名前のゼロサイズのファイルに置き換えます。TeamCity サーバーを起動する
ただし、データベースが自動的に回復しない場合は、手動で修正できる可能性はほとんどありません。
内部 (HSQL) データベースは本番環境で使用するには十分に安定していないため、TeamCity を評価目的以外で使用する場合は 外部データベースの使用を強くお勧めします。
データベースの破損が発生した場合は、最後の正常なバックアップを復元するか、設定を保持したままビルド履歴とユーザーを削除できます。 外部データベースへの移行を参照してください。
トランザクション... ログがいっぱいです
このエラーは、MS SQL または Sybase データベースで発生する可能性があります。 この場合、TeamCity データベースのトランザクションログを増やすことをお勧めします。 ログサイズは、システム内のビルドエージェントの数と、すべてのエージェントが毎日報告するテストの数に応じて、1 - 16 GB になる可能性があります。
テーブル 'table_name' がいっぱいです
このエラーは MySQL データベースで発生する可能性があります。 このエラーは、データベースファイルが配置されているディスクまたは一時ディレクトリのいずれかで、データベースの空き領域が不足していることを示しています。
表領域 ... 内の ... セグメント ... を拡張できません
このエラーは Oracle データベースで発生する可能性があります。 このエラーは、データベースのディスク上のスペースが不足しているか、指定されたクォータが不足しているため、Oracle がテーブルまたはインデックス用のスペースをこれ以上獲得できなかったことを示しています。
MS SQL Server で NOCOUNT が有効です
teamcity-サーバー.ログ は、MS SQL データベースサーバーでサポートされていない NOCOUNT オプションが有効になっていることを報告します。 設定を無効にするには、DBA に連絡してください。
MySQL JDBC ドライバーエラー: PacketTooBigException
ER_NET_PACKET_TOO_LARGE エラー（PacketTooBigException/ クエリのパケットが大きすぎます）は、サーバー側の max_allowed_packet 構成変数(英語)が低い値に設定されているか、デフォルトの値のままになっていることが原因です。
この変数は MySQL 通信バッファの最大サイズを制御します。Windows 版 MySQL 5.6 ビルドでは 4MB がデフォルトですが、一般的な Linux ディストリビューション (例 例。 Debian と Fedora Core) では、この変数のデフォルトは i686 と amd64 の両方のアーキテクチャで 16MB です。
データベースの文字セット/照合順序関連の問題
文字セット/照合順序の不一致
TeamCity は文字セット/照合順序の不一致エラーを報告します: データベースのテーブル/列の文字セットまたは照合順序が、データベーススキーマのデフォルトの文字セットまたは照合順序と同じではありません。 TeamCity は一部の varchar フィールドに Unicode 文字セットを強制するため、データベースのデフォルトとして非 Unicode 文字セットを使用している場合にこのメッセージが表示されることがあります。 データベースが弊社の 推奨事項に従って構成されていることを確認してください。
TeamCity に ???? が表示される 各国語文字の代わりに
TeamCity のテキストでローカル文字 (たとえば VCS メッセージ、テスト名、ユーザー名) を許可する場合は、適切な文字セットのデータベースに移行する必要があります。
バックアップからの復元時の "Unique key violations" または "Duplicates found" エラー
ソースデータベースと宛先データベースの文字セット (または照合順序) が同じではなく、宛先文字セットのカーディナリティがソースデータベースのカーディナリティより小さい場合、バックアップからの TeamCity サーバーの復元は "一意鍵違反" または "重複が見つかりました" のようなエラーで失敗することがあります。
問題を解決するには、接続先データベースに適切な文字セット（および照合順序）を選択して設定します。
大文字と小文字の区別については、考えられる遷移は次のとおりです。
CS > CS
CI > CS
CI > CI
ただし、常に CS を使用することをお勧めします。
ソース文字セットが Unicode または UTF の場合、宛先文字セットも Unicode または UTF でなければなりません。 ソース文字セットが 8 ビットの非 UTF である場合、宛先文字セットは同じでも Unicode/UTF でもかまいません。
文字セット/照合順序関連の問題を解決する
問題を解決するには、以下のステップを実行してください。
適切な文字セットと照合順序を持つ新しいデータベースを作成します。 unicode で大文字小文字を区別する物件があります。. 照合順序の使用をお勧めします: PostgreSQL と MySQL の手順を参照してください。 MySQL では、
utf8_binまたはutf8mb4_binが推奨されます。
文字セットの詳細については、 PostgreSQL、 MySQL、 MS SQL のドキュメントも参照してください。現在の
<TeamCity データディレクトリ>/config/データベース.propertiesファイルをコピーし、コピー内のデータベース参照を新しく作成されたデータベースに変更します。TeamCity サーバーを停止します。
maintainDBツールを使用して新しいデータベースに移行します。maintainDB migrate [-A <path-to-data-dir>] -T <new-database-properties-file>データベースのサイズに応じて、移行には数分から数時間かかる場合があります。
maintainDB ツールの詳細については、 このセクションを参照してください。データベースの移行が正常に完了すると、
maintainDBツールは、新しいデータベースへの参照を使用して<TeamCity データディレクトリ>/config/データベース.propertiesファイルを更新します。 ファイルが更新されていることを確認してください。 ツールが自動的に更新しない場合は、手動でファイルを編集してください。TeamCity サーバーを起動します。
MySQL 例外: 指定されたキーが長すぎます。最大キー長は 767 バイトです
インデックス列のサイズが大きすぎます。 最大列サイズは 767 バイトです
MySQL データベースの文字セットを確認してください。 utf8 文字セットを使用することをお勧めします。
データベースで utf8mb4 文字セット（MySQL 5.5 以降で使用可能）を使用している場合は、次の InnoDB 構成オプション（my.cnf または my.ini の [mysqld] セクションの下）を実行するように設定します。
767 バイト（最大 3072 バイト）より長いインデックスキー接頭辞の
innodb_large_prefix=1は、DYNAMIC 行形式（MySQL 5.7.7 で非推奨）を使用する InnoDB テーブルで許可されます。DYNAMIC 行フォーマットを有効にするための
innodb_file_format=Barracudaバラクーダファイル形式を有効にする
innodb_file_per_table=1
上記のパラメーターのデフォルト値は次のとおりです。
MySQL 5.5 | MySQL 5.6 | MySQL 5.7 | MariaDB 5.5 | MariaDB 10.0 | MariaDB 10.1 | MariaDB 10.2 | |
|---|---|---|---|---|---|---|---|
innodb_large_prefix | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
innodb_file_format | Antelope | Antelope | Barracuda | Antelope | Antelope | Antelope | Barracuda |
innodb_file_per_table | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
データベースサーバーのバージョンに応じて、以下の設定変更を行う必要があります。
MySQL 5.5:
innodb_large_prefix=1innodb_file_format=Barracudainnodb_file_per_table=1
MySQL 5.6 および MariaDB 5.5 から 10.1:
innodb_file_format=Barracudainnodb_file_per_table=1
MySQL 5.7\+ および MariaDB 10.2\+ ではデフォルトを使用します。変更は不要です。
MySQL の 'Incorrect string value' エラー
データベースが
utf8mb4文字セットとutf8mb4_bin照合順序を使用していることを確認してください。 そうでない場合は、 DB 文字セットと照合順序を変更してください。文字セットと照合順序が適切に設定されているにもかかわらず新しいエラーがまだ発生する場合、問題は MySQL のデフォルト charset が utf8mb4 ではないことです。
my.cnfの[mysqld]セクションで次のオプションを指定して、MySQL サーバーがデフォルトでutf8mb4を使用するように設定します:character_set_server = utf8mb4collation_server = utf8mb4_binmy.cnfの変更を有効にするには、MySQL を再起動します。
MS SQL データベースでの 'This driver is not configured for integrated authentication' エラー
TeamCity のインストール中に、Windows 統合セキュリティを使用して MS SQL データベースに接続し作成するとき、次のエラーが発生することがあります: "SQL error when doing: Taking a connection from the data source: This driver is not configured for integrated authentication."
この問題の最も一般的な原因は、 sqljdbc_auth.dll MS SQL 共有ライブラリと TeamCity が使用する JRE のビット数が異なることです。
問題を解決するには、次の手順に従います。
必ず MS SQL ネイティブドライバ（マイクロソフトダウンロードセンター(英語)からダウンロード可能）を使用してください。
正しい JRE ビット数を使用してください。TeamCity を、
sqljdbc_auth.dllMS SQL 共有ライブラリと同じビット数の Java で実行していることを確認します。 デフォルトでは、TeamCity は 64 ビット Java を使用します。 ただし、32 ビットと 64 ビットの両方の Java バージョンを 使用できます。
必要な JRE で TeamCity を実行するには、次のいずれかを行います: * TEAMCITY_JRE 環境変数を設定します * または <TeamCity ホーム>\jre から TeamCity にバンドルされている JRE を除去し、 JAVA_HOME を設定します。
32 ビット Java から 64 ビット Java への更新 も参照してください。
プロトコル違反エラー (Oracle のみ)
このエラーは、Oracle JDBC ドライバが Oracle サーバーと互換性がない場合に発生する可能性があります。 例: Oracle JDBC ドライバーのバージョン 11.1 は、Oracle サーバーのバージョン 10.2 と互換性がありません。
この問題を解決するには、Oracle サーバーのインストールに含まれる Oracle JDBC ドライバーを使用するか、Oracle サーバーと同じバージョンのドライバーを ダウンロードしてください。
MySQL データディレクトリのサイズ
MySQL データディレクトリには、大量のディスク容量を消費する可能性のある大きな <ホスト名>-bin.<インデックス> ファイルが含まれている場合があります。 これらのファイルは TeamCity とは関係ありません: MySQL データベースに対する変更の連続したログを含む MySQL サーバーのバイナリログファイルです。 これらのファイルは、MySQL サーバーのレプリケーションとデータ復旧に使用されます。
デフォルトでは、バイナリログファイルは 30 日後に自動的に期限切れになるように設定されています。
一般的な Maven の問題
TeamCity ビルド構成でよく見られる Maven 関連の問題には 2 種類あります:
ビルド構成の Maven タブにエラーメッセージが表示される: "Maven プロジェクト情報の収集中にエラーが発生しました ..."
Maven 依存関係トリガーがアクティブ化されたビルド構成のエラーメッセージ: 「Maven 依存関係の更新を確認できません ...」このようなエラーメッセージが表示されているにもかかわらずビルド構成が正常にビルドされる場合、これらのエラーは サーバー側の Maven 設定ミス が原因である可能性があります。
Maven タブの情報を収集するため、または Maven 依存関係チェック (トリガー用) を実行するために、TeamCity は組み込みの Maven を実行します。 実行は サーバーマシン上で行われ、 agent-side maven 設定には アクセスできません。 TeamCity は、 Maven サーバー側設定で説明されているように、サーバー側で settings.xml ファイルを個別に解決します。
サーバー側 settings.xml ファイルにリモートリポジトリ、プロキシ、ミラー、プロファイル、認証情報などに関する正しい情報が含まれているかどうかを確認することは理にかなっています。
"Critical error in configuration file" エラー
このエラーが発生した場合、TeamCity データディレクトリに保存されている設定が不整合な状態であることを意味します。 これは、ファイルを手動で変更した後、または新しいバージョンの TeamCity が不整合を報告し始めた場合に発生することがあります。
問題を解決するには、サーバーファイルシステム上でメッセージに示されたファイルを編集できます。 (手動編集を行う前に、必ずファイルのバックアップコピーを作成してください)。 通常、変更を有効にするためにサーバーを再起動する必要はありません。
ID "XXX" の VCS ルートは存在しません
ビルド設定またはテンプレートが、システムで定義されていない VCS ルートを参照しています。 対処方法: VCS ルートを復元するか、指摘された ID を使用して新しい VCS ルートを作成するか、メッセージに記載されたファイルを編集して、VCS ルートへの参照を削除します。
TeamCity のインストールに関する問題
インストール後に TeamCity Web UI にアクセスできない場合、別のプログラムがすでに使用しているポートで TeamCity を実行している可能性があります。 TeamCity インストールを 確認して構成します。
TeamCity NuGet Feed の問題
部分的な TeamCity NuGet Feed に関する問題 (たとえば NuGet パッケージの欠落) が発生している場合は、TeamCity NuGet Feed のインデックスを再作成する必要があることがあります。
TeamCity に利用可能なすべてのパッケージのインデックスを強制的に再作成させ、NuGet パッケージリストをリセットするには、サーバー 管理 | 診断 | キャッシュ に移動し、 buildsMetadata Reset リンクを使用します。
.NET 関連の TeamCity ツールの問題
起動時のパフォーマンスの問題
TeamCity エージェントにインストールされているバージョン 4.0 未満の .NET Framework は、Microsoft が適用する Code access security (CAS) ポリシーにより、.NET 関連の TeamCity ツールのパフォーマンス問題を引き起こす可能性があります。
この問題を解決するには、次のいずれかの方法を使用してください。
すべてのエージェントで、 Microsoft のドキュメント(英語)に記述されている以下の設定を
machine.configファイルに追加します。<configuration> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration>この 外部ブログ投稿(英語)で説明されているように machine.config ファイルを変更し、カスタムスクリプトを使用するなどして、この構成ファイルをすべてのエージェントに渡すことができます。
または、TeamCity エージェント上の .NET Framework をバージョン 4.0 以上にアップグレードします。 詳細は Microsoft のドキュメント(英語)にあります。
手動入力が必要なツールの使用、特に Extended Validation コード署名
TeamCity エージェントで実行されるビルド手順中に、手動操作が必要なツールを使用したい場合があります。 これは TeamCity 固有の問題ではないため、一般的な方法で対処する必要があります。
Windows では、TeamCity エージェントをサービスとしてではなく、デスクトップにアクセスできるように実行するため、自動ユーザーログオンを構成することを検討してください。 関連する詳細。
機能が何らかの理由で組み込まれているため、Extended Validation(EV) コード署名の簡単な解決策はありません。 スタックオーバーフロー(英語)の問題についていくつかの議論があります。 適切なソリューションは、独自の承認アプローチを使用して専用サービスを実装し、それを介してバイナリに署名するようです。
Tomcat エラー: Request Header too large
デフォルトでは、Tomcat は要求および応答の HTTP ヘッダーに 4096 バイト (4KB) の制限を設定します。 ヘッダーに含まれる Cookie が多すぎる場合 (たとえば、エンドユーザーと TeamCity の間にあるプロキシサーバーからのもの)、またはそのサイズが大きすぎる場合、ユーザーは TeamCity の閲覧時に 400: リクエストヘッダーが大きすぎます または 502: 不正な Gateway エラーに遭遇することがあります。 この問題の原因を特定するには、ブラウザー開発者コンソールで影響を受けるヘッダーをインスペクションすることをお勧めします。
この問題を解決するには、 $TOMCAT_HOME/conf/server.xml ファイル内のすべての関連コネクターの maxHttpHeaderSize パラメーター値を編集して、Tomcat ヘッダーの制限を増やします。 例: 次のサンプルでは、パラメーター値を 65536 に設定して、制限を 64KB に増やします。