MID サーバーのアップグレードプロセス - MID サーバー自体のアップグレードで起こることIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } MID サーバーのアップグレードプロセスはどのように機能するか？ これを知っておくと、問題が発生した場合にデバッグし、どこで問題が発生したかを正確に特定するのに役立ちます。 この記事では、パッチのインスタンスのアップグレードが終了した直後に実行される、MID サーバーの自動アップグレード時に発生するプロセスについて説明します。 これは、Windows ホストと Vancouver バージョンに基づいています。Linux プロセスは基本的に同じですが、一時フォルダーの場所が異なり、バッチファイルの代わりにシェルスクリプトを使用しています。 Windows ホストでの MID サーバーのアップグレードプロセス アップグレードチェックは、次のいずれかの方法でトリガーされます。 MID サーバーの起動時に StartupSequencer スレッドによってトリガーされる。インスタンスのパッチまたはアップグレードの最後に、インスタンスが topic=SystemCommand, source=autoUpgrade ジョブを、その時点で稼働しているすべての MID サーバーに ECC キューを介して送信するときにトリガーされる。 この時点で、他の MID サーバー関連のプラグインも MID サーバーに再起動要求を送信する場合があります。1.1 毎時、MID サーバーの「AutoUpgrade.3600」スレッドが実行される際にトリガーされる。そのチェックを停止することはできません。MID サーバーフォームで「MID のアップグレード」関連リンクがクリックされた場合にトリガーされる。 「MID サーバーのアップグレードが必要かどうかを確認しています。」というメッセージが MID サーバーエージェントログに書き込まれ、MID サーバーのバージョンを確認するためにインスタンスが照会されます。 MID サーバーは、agent\package\meta\mid-core.meta.properties および mid-jre.meta.properties ファイルの内容からインストールされた「core」および「jre」パッケージの buildstamp を認識します。「core」は MID サーバーアプリケーションであり、MID サーバーがアップグレードされるたびにアップグレードされます。「jre」は主要なリリースごとにアップグレードされる可能性が高いため、core よりも古い buildstamp である可能性があります。2.3「MIDAssignedPackages」スクリプト化 SOAP サービスを使用して何がアサインされているかをインスタンスに確認します。要求には OS、アーキテクチャ、および JVM バージョンが含まれ、対応するコア、jre、およびアップグレードパッケージ名/URL が返されます。 アサインされるパッケージは、mid.buildstamp システムプロパティのインスタンスバージョンの MID Buildstamp から取得されます。これは常に現在のインスタンスバージョンと一致し、インスタンスをアップグレードするたびに自動的に更新されます。インスタンスの stats.do ページでは、手動で確認するための MID Buildstamp も報告されます。glide.war および glide.war.assigned システムプロパティを使用して、インスタンスのロールバックが発生したかどうかを確認します。2.1SOAP 要求が処理される特定のインスタンスアプリノードが何らかの理由でまだアップグレードおよび再起動されていない場合、アップグレード前のバージョンが返されることがある2.2MID サーバーの mid.pinned.version パラメーターは、インスタンスのバージョンを上書きします。これは、インスタンスのアップグレード時に MID サーバーのアップグレードを防ぐ唯一の方法であり、不一致の MID サーバーを実行する危険性があるため、廃止され、ドキュメントから削除される予定です。2.4アサインされた Java JRE バージョンは、SOAP Web サービスのスクリプト内で変数としてハードコーディングされています。これが MID サーバーにインストールされている JRE にすでに一致している場合、JRE のアップグレードはスキップされます。つまり、レコードはインスタンスの最新アップグレードのすぐに使えるバージョンにし、必要に応じて元に戻す必要があります。このスクリプトはカスタマイズしないでください。そうしないと、アップグレード時にスキップされます。Linux ホストが 32 ビットの場合、または glibc が v2.17 より前のバージョンである場合、Rome JRE のアップグレードもスキップされます。 「インストール済み」が「アサイン済み」と比較され、「不足している」パッケージが差分となり、後で手順 5 でダウンロードおよびインストールされます。アサインされたバージョンがインストールされているバージョンよりも古い場合は、ダウングレードが試行されますが、問題が発生する場合もあります。古いインスタンスバージョンには、ダウングレードプロセスの開始時に MID サーバーが想定していた新しいコード/API が含まれていない可能性がありますが、MID サーバーはその後のコード実行を継続します。 MID サーバーのエージェントログには、次のような内容が記録されます。「アサイン済み」には、常に mid-upgrade パッケージと mid-core パッケージが含まれます。「アサイン済み」と「不足」には、アップグレードが必要な場合にのみ jre の中間エントリが含まれますが、この例では含まれていません。Paris から Quebec へのアップグレード、または Quebec から Rome へのアップグレードには JRE アップグレードが含まれますが、通常、メジャーバージョン内の後続のパッチやホットフィックスには含まれません。 Current packages: Installed: [mid-core.quebec-12-09-2020__patch0-hotfix3-01-20-2021_01-21-2021_0905.universal.universal.zip, mid-jre.quebec-12-09-2020__patch0-hotfix1-01-04-2021_01-06-2021_1339.windows.x86-64.zip] Assigned: [mid-upgrade.quebec-12-09-2020__patch1-02-18-2021_03-01-2021_1225.universal.universal.zip, mid-core.quebec-12-09-2020__patch1-02-18-2021_03-01-2021_1225.universal.universal.zip] Missing: [mid-upgrade.quebec-12-09-2020__patch1-02-18-2021_03-01-2021_1225.universal.universal.zip, mid-core.quebec-12-09-2020__patch1-02-18-2021_03-01-2021_1225.universal.universal.zip] Downloaded: [] MID サーバーエージェントログに「Setting mid status to Upgrading」と書き込まれます。 MID サーバーレコードは「Status=Upgrading」3.1として設定され、一時停止され、新しいジョブ (システムコマンドを除く) はそれ以上取得されません。インスタンスの MID サーバーアップグレード履歴が更新されます。 MID サーバーエージェントログに「アップグレード前検証テストを実行しています」と書き込まれます。 MID サーバー構成パラメーター mid.upgrade.run_precheck=false でない限り、これらの事前チェックはデフォルトで実行されます。 その場合、アップグレード履歴の [アップグレード前のチェック] ステージはインスタンスで [スキップ] とマークされます。アップグレード履歴の「アップグレード前チェック」ステージは、インスタンスでスキップ済みとしてマークされます。 オンプレミスインスタンス、隔離された環境、または規制対象市場のデータセンターインスタンスの場合、このテストに合格できず、ワークアラウンドが必要になる場合があります。4.1、4.8「mid-upgrade...preUpgradeCheck.zip」ファイルが https://install.service-now.com からダウンロードされます。Quebec 以降、ホスト install.service-now.com の証明書チェックが行われます。通常、証明書はインスタンスへの接続と同じものであるため、これは問題ありません。署名済み preUpgradeCheck.zip ファイルがデジタル署名の検証に失敗した場合、アップグレードは失敗します。4.4内容が TEMP フォルダーに解凍されます。Rome 以降、これは agent\work 内にあります。Quebec 以前の場合は OS/Service User temp フォルダーです。Windows では、シンプルな PowerShell スクリプトを実行して PowerShell のバージョンとユーザー権限を確認するテストが含まれます。4.2、4.3、4.7アプリケーションエクスペリエンスが実行されているなど、アップグレードが失敗する原因となるいくつかの既知の構成もチェックされます4.6。一時ファイルが削除されます。すべてが順調な場合、「アップグレード前の検証テストに成功しました。アップグレードプロセスを続行します」と表示されます。アップグレード履歴の「アップグレード前チェック」ステージは、インスタンスでスキップ済みとしてマークされます。障害が発生した場合、特定のエラーまたはブロックされない警告がエージェントログと MID サーバーの問題テーブル [ecc_agent_issue] に追加されます4.5。アップグレード履歴の「アップグレード前チェック」ステージは、インスタンスで失敗としてマークされます。 不足しているパッケージの ZIP ファイルをダウンロードする アップグレード履歴の「アップグレード前チェック」ステージは、インスタンスで進行中としてマークされます。mid-upgrade...zip および mid-core...zip は常にダウンロードする必要があり、Java ランタイムのアップグレードも必要な場合は、mid-jre...zip もダウンロードする必要があります。必要な特定のファイル名は、上記の現在のパッケージチェックの「Missing: [...]」行に表示されます。ZIP ファイルは \agent\package\incoming\ フォルダーに保存されます。ZIP ファイルに META-INF フォルダーが含まれている場合は、署名がチェックされ、ZIP ファイルが改ざんされていないことが確認されます。4.5すべてが「パッケージが正常にダウンロードされました」とログに記録された場合、処理を続行します。インスタンスのシステムプロパティ mid.download.through.instance=true の場合、ZIP ファイルは install.service-now.com から直接ではなく、インスタンスを介してダウンロードされます。インスタンス内でセマフォのブロックを引き起こすため、デフォルトで false に設定する必要があります。5.1ソケットのタイムアウトなどが原因でファイルが不完全な場合、ファイルは削除され、ダウンロードが再試行されます。最大再試行数に達した場合、またはファイルの削除で問題が発生した場合は、手動で解決する必要があります。アップグレード履歴の「アップグレードパッケージのダウンロード」ステージは、インスタンスで完了または失敗としてマークされます。 ZIP ファイルの展開 アップグレード履歴の「アップグレードパッケージの解凍」ステージは、インスタンスで進行中としてマークされます。必要なものはすべて揃ったので、MID サーバーのエージェントログに「Upgrading MID server」と書き込まれます。ZIP ファイルを一時フォルダーに解凍します。ウイルス対策/セキュリティソフトウェアは、これらの一時ファイルの作成をブロックし、アップグレードを中断する可能性があります6.5。Rome より前のバージョン (以前のバージョンからの Rome 以降へのアップグレードを含む) では、wrapper-override.conf で上書きされない限り、OS の一時フォルダーが使用されます6.1。 これは、C:\Windows\TEMP\<ランダムな 13 桁の数字>-0\ のようなランダムなフォルダー名です。その後は、\agent\work\upgrade_temp\<ランダムな 13 桁の数字>-0\ の下の一時フォルダが使用されます。そのフォルダに対する権限は完全に制御できるため、OS 共有の一時フォルダーで発生していた問題は少なくなります。インスタンスがすでに Rome 以降にアップグレードされている場合、これは Rome からのアップグレードのデフォルト動作になります。mid.upgrade.use_os_temp_folder によってその動作が制御されます。デフォルトは false になります。各ファイルは個別に「解凍中：」とログに記録されます。アップグレード履歴の「アップグレードパッケージの解凍」ステージは、インスタンスで完了としてマークされます。 アップグレードプロセスを開始し、シャットダウンします アップグレード履歴の「FipsConversion」ステージは通常スキップされ、「MID サーバーが FIPS 適用モードではないか、mid-jre が更新されていません。変換は必要ありません」というメッセージが表示されます。FIPS 承認済みモードが有効になっている場合、受信 JRE には、正しいタイプではない可能性があるトラストストア (cacerts) ファイルが含まれます (2021 年 3 月 30 日現在、そのタイプは BCFKS)。ここでは、そのファイルの変換と、正しいタイプを反映するための java.security ファイルの更新が処理されます。失敗した場合は、アップグレード履歴とエージェントログに「アップグレード中に FIPS ファイル変換を試行して例外がスローされました」と表示され、FipsFileConversionFailure の MID サーバーの問題レコードが作成されます。 アップグレード履歴「MigrateTrustStore」ステージは、cacerts ファイルにお客様が追加した証明書を保持するためのステージです。通常、これはパッチおよびホットフィックスのアップグレードではスキップされ、「トラストストアの移行は必要ありません (JRE のアップグレードは必要ありません)」というメッセージが表示されます。メジャーバージョンのアップグレードでは、これを実行する必要があります。正常に動作した場合は、「トラストストアの移行が完了しました。」と「元のトラストストアのバックアップは次の場所にあります:」とログに記録するか、CACertsに証明書が追加されていない場合は「トラストストアの移行のために識別された証明書がありません。」と記録します。 エラーのある TrustStoreMigrationFailure MID サーバー問題レコードが作成されました。アップグレード履歴の「バイナリファイルの展開」ステージが「進行中」に設定されます。Windows 上の「WMI Collector Service」はもう存在しないはずですが、存在していた場合は停止します。「current= でアップグレードシナリオを判断できません」という警告は、「Rome 以降のバージョンから Rome より前のバージョンへのダウングレードを検出しています」というコードに由来するため、無視できます。これは現在では発生する可能性が極めて低くなりました。Quebec 以降、java と Tanuki のプロセスが後のステップで本当に停止されることを確認するために、「MID とラッパー PIDを ... agent\conf\pids に書き込んでいます」と表示されます。失敗した場合は、「MID プロセスをファイルに書き込めませんでした。記録された PID なしでアップグレードを続行します」というログが記録されます。Washington DC 以降、ファイルにサービス名が書き込まれます。これは特権エスカレーションの防止に関連しています。「...agent\service_name にサービス名を記述しています」と出力され、失敗した場合は「ファイルにサービス名を書き込めませんでした。記録されたサービス名なしでアップグレードを続行します」というログが記録されます。DistUpgrade ファイルが以前のアップグレードから残っている場合は、削除されます。「ファイル ...\agent\conf\DistUpgrade の削除を試行します」と表示され、次に予想どおり「ファイルが見つからないか、削除できません」と表示されます。そこにそのファイルがあることを想定していないためです。アップグレードプロセスに使用する JRE (java 実行可能ファイル) がチェックされ、そこに存在し、使用可能であり、ユーザーが実行権限を持っていることが確認されます。これが失敗した場合の警告には、「解凍された JRE の Java 実行可能ファイルが見つかりません」、「アップグレード用に解凍された JRE を準備できません」、および例外として「アップグレードに使用する現在の JRE またはパッケージ化された JRE を特定できません。原因は次のとおりです」などがあります。midupgrade.conf が存在しない場合は作成されます。または、エラー「パラメーターを渡すためのアップグレード構成ファイルを作成できません。プロセスは次の例外で失敗しました。」が表示されます。次に、変更されたファイルのリストが入力されます。ファイルの内容は「mid.upgrade.replace_changed_files=」の後にファイル名のリストが続きます。そのリストを作成できない場合は、警告「<ファイル名> に mid.upgrade.replace_changed_files (...) を保存できません。次の例外で失敗しました。」が表示されます。Windows では、「サービスの再インストール - サービスの再インストールは Linux OS でのみサポートされています」と表示される場合がありますが、無視しても問題ありません。Linux では、次のいずれかが表示されます。 「ReinstallService -- サービスの再インストールが必要です。サービスを再インストールして MID サーバーのアップグレードを続行します」というメッセージが表示され、アップグレード履歴の「サービスの再インストール」ステージが「進行中」に設定されます。 警告「ReinstallService -- ユーザーには、MID アップグレード中にサービスを再インストールする権限がありません。サービスを再インストールせずに MID のアップグレードが続行されます」というメッセージが表示され、「MID サーバーのアップグレードでサービスを再インストールする必要があります。ただし、現在のユーザーにはサービスをインストールする権限がありません (root/admin ユーザーのみが特権を持っています)。安全でないサービスを再インストールせずにアップグレードを続行します。サービスを手動で再インストールすることをお勧めします。同じバージョンの MID サーバーラッパーでサービスがインストールされていることを確認してください。」というメッセージが表示されます。MID サーバーの問題レコードが作成されます。「MID サーバーのアップグレード中に再インストールサービスの検証に失敗しました。必要なサービスの再インストールがスキップされた可能性があります。アップグレード後に MID サーバーと同じバージョンでサービスがインストールされていることを確認してください。」または、何もする必要がなく、既存の MID サーバーの問題レコードが解決済みとしてマークされます。 「Stopping MID server. Bootstrapping upgrade.」と「MIDUpgrader.startUpgradeRunner(), OperationalState=UPGRADING」が MID サーバーエージェントログに書き込まれ、現在 TEMP フォルダーにあるアップグレードバイナリが実行されます。6.1。そのために \<ランダムな数>-0\\upgrade-wrapper\bin\glide-dist-upgrade.bat ファイルが実行されます。これが失敗すると、最終的に「ブートストラップに失敗しました。」と表示されることがあります。 一時フォルダー名は agent\work\upgrade.info に書き込まれ、「アップグレードマーカーファイルにマーカー '<パス>' を追加しました。」とログに記録されます。これが失敗した場合、アップグレードマーカーファイル <パス> を書き込めません。マーカー <行> は手動で削除する必要があります。」と表示されます。Tokyo 以降では、MID サーバーパラメーター mid.skip.dist.signal.for.shutdown=true が設定されていない場合、MID サーバーはアップグレードプロセスが開始されたことの確認を待機するようになりました。 このパラメーターの値は、「スキップディストリビューション信号チェック：false」としてログに記録されます。これにより、アップグレード先のバージョンの「assignedVersion：」もログに記録されます。そのアサインされたバージョンからファミリーリリースを作成できない場合 (GlideFamilyRelease.releaseIsAfterRelease を使用)、警告 "Unable to determine release version with assigned = "が表示されます。このチェックは、Tokyo より前のバージョンであるかどうかを確認するために行われ、Tokyo より前のバージョンである場合、チェックはスキップされます。アップグレードは停止せず続行されます。MID サーバーは DistUpgrade ファイルをチェックするようになり、正常に開始された場合はアップグレードプロセスによって書き込まれます。これはまだ確認していませんが、10 分の間、10 秒ごとに "Waiting for upgrade process started signal"と"DistUpgrade file is not present." がログに記録されます。10 分経っても確認がない場合は、待機を中止して「..\agent\conf\DistUpgrade ファイルの削除を試行します」、「ファイルが見つからないか、削除できません」とログに記録され、警告/MID サーバーの問題レコード「ソース「アップグレードプロセスを起動できませんでした」に対して「アップグレードプロセスステータスを受信できません」というメッセージを含む一意の MID の問題を作成しています」と表示されます。 注意：Orlando より前のバージョンでは、このプロセスは「ServiceNow プラットフォームディストリビューションアップグレード ()」という名前の新しい Windows サービスでした。MID サーバーサービスには、ローカルの Administrators グループのメンバーである「ログオンユーザー」が必要です。そうしないと、一時的なアップグレードサービスの作成および開始ができません。アップグレードプロセスが開始されたことが確認されると、シャットダウンプロセスの開始時に「 MID ステータスをダウンに設定します」がログに記録されます。この時点で、ラッパーログには「ServiceNow MID サーバー_xxx サービスを停止しています...」と記録されます。"MID Server stopped"とログに記録されますが、必ずしもすべてのスレッドが強制終了されていたり、JVM がすでに停止していたりするわけではありません。まだ終了していないプローブが存在し、それらはまだ終了する必要があるか、例外でクラッシュする可能性があります。6.6 予期される最後のエージェントログエントリは "Thread-0 Main.handleStop() after shutdown, OperationalState=UPGRADING" です。この間、ラッパーログにはいくつかの「停止を待機中です...」がログに記録され、実行中のすべてのスレッド/プローブが終了するまで 5 秒ごとに繰り返し表示されます。最後に、ラッパーログの「<-- Wrapper Stopped」は、JVM がシャットダウンしたことを示しています。これで、Java アプリケーション用 (ラッパーサービス用) にロックされたファイルがなくなります。Madrid6.2 では通常より 2 分以上長くかかり、他のスタックしたプローブがある場合は 15 分以上かかることがあります6.3、7.12。 その間、別のアップグレードプロセスが開始され、次の処理が実行されます。 これは、上記の「アップグレードをブートストラップしています」ログの直後、 MID サーバーのシャットダウンが完了する前に開始されます。完了するまでに数分かかる場合があります。これは、Tanuki ラッパーを使用して起動された別の Java アプリケーションです。このプロセスは、TEMP フォルダー内の glide-dist-upgrade.log に記録されます。 これがメインの wrapper.log にコピーされるのはさらに後になります。エラーまたは警告はすべてログに記録されます。この手順でアップグレードが失敗した場合は、このファイルが何が起こったのかを示す唯一の手掛かりになる可能性があります。「ServiceNow プラットフォームディストリビューションアップグレード (xxx) サービスがインストールされていません - 指定されたサービスはインストール済みサービスとして存在しません」と Orlando および Paris6.4 のログに記録されます。無視してください。Java ラッパーがアップグレーダーアプリケーションを起動すると、「com.snc.dist.mid_upgrade.UpgradeMain$1 start」とログに記録されます。Tokyo 以降、ファイルが agent\conf\DistUpgrade に書き込まれ、メインの MID サーバーサービスにシャットダウン可能であることが伝達されます。このアップグレードプロセスは、MID サーバーサービスが完全にシャットダウンするまで待機してから、7.9 を続行します。最初に、「実行中：番号」を返すまで数秒ごとに (「agent\bin\mid.bat status」を使用して) Tanuki ラッパーを照会し、その結果が wrapper.log に直接書き込まれます。 Quebec 以降では、過去にファイル agent\conf\pids に記録された MID およびラッパープロセスが本当に停止していることもチェックされます。両方が停止したら、「プロセス (pid=xxx) が実行されていません」のような 2 つのエントリが出力されることが想定されます。 注意：サービスモニタリングツールなど、シャットダウン後に MID サーバーサービスが再度開始された場合、新しいサービスの PID が異なるため、アップグレードは中断され、新しく開始されたサービスからのファイルログがなくても続行されます。Xanadu以降、デフォルトで有効になっているロールバック機能が追加され、ファイル操作に問題が発生した場合に、アップグレード プロセスですべてのファイルを元の状態に戻すオプションが提供されます。MID Server プロパティ mid.upgrade.enable_rollback=false は、この機能を無効にします。bin および lib フォルダーは、bin_old および lib_old に名前が変更され、bin および lib にコピーされます。bin_old および lib_old は、必要に応じて後でバックアップとして使用されます。ロールバックが発生すると、「MID Server のアップグレードに失敗しました。MID Server は現在、以前のバージョンを使用して実行されています。」または「MID Server のアップグレードに失敗しました。以前のバージョンへのロールバックも失敗しました。」がログに記録されます。agent\bin および agent\lib フォルダー内のファイルが MID サーバーのインストールから削除されます。ファイルがまだロックされている場合は 1 秒ごとに再試行されるため、MID サーバーが最終的に正常にシャットダウンした場合、MID サーバーがまだシャットダウン中であるという事実は問題になりません。「com.snc.dist.mid_upgrade.UpgradeMain wipeDirs」がログに記録されます。10 分後もファイルがロックされている場合、7.1、7.12のアップグレードは失敗します。アップグレードサービスは停止し、MID サーバーは起動せず、「ダウン」のままになります。Paris 以降では実際のプロセスが停止していることのチェックが追加され、7.14 を強制終了しようとすると、Java およびラッパープロセスがまだ実行されていたことが確認される可能性があります。スタックダンプや実行中のサービスの一覧表示は行わないため、複数の MID サーバーが実行されているときにプロセス ID (PID) をインストール/サービスと照合するための情報は、このログから簡単には得られません。Rome 以降では、このロギングははるかに改善されています。エージェントログに「MID サーバーが停止しました」と「シャットダウン後の Main.handleStop()、OperationalState=UPGRADING」と表示されている場合は、JVM とラッパーが実際に停止したわけではありません。また、MID サーバーがシャットダウンしたことを確認するために、wrapper.log に「<-- ラッパーが停止しました」が表示されている必要があります。注意：メインサービスからのこれらのログエントリは、アップグレードログが後でラッパーログにコピーされるため、アップグレードログエントリと時系列にはなりません。ファイルロックエラーは、MID サーバーが実際にシャットダウンした後の 10 分のタイムアウト前に発生する可能性があります。たとえば、アプリケーションエクスペリエンス 7.3、および Cisco AMP 7.4 や Dell SecureWorks Red Cloak 7.10 などのウイルス対策ソフトウェアが原因です。まだ確定していない他の原因があります (7.5)。これらの他の MID サーバー以外のプロセスは、アップグレードサービスがファイルを削除しようとすると、一時的にファイルのロックを保持します。このような既知の原因が特定され、アプリケーションエクスペリエンスが 4.6 についてすでにチェックされている場合に、問題レコードを作成するためのコードが MID サーバーに追加されています。ウイルス対策が InjectorService.exe などの疑わしいファイルを削除すると、アップグレードでも削除しようとすると例外が発生します。7.11 のフラグを立てるため、MID サーバーを停止したままアップグレードが失敗するアップグレードサービスが停止し、MID サーバーは起動されず、「ダウン」のままになります。Rome 以降では、置き換える必要があるファイルのみが置き換えられます。これは、過去に midupgrade.conf に記録された内容に基づきます。Rome より前は、実際に変更されたファイルが少ない場合でも、bin フォルダと lib フォルダの内容全体が削除され、置き換えられていました。たとえば、Tanuki ラッパーの実行可能ファイル bin\wrapper-windows-x86-64.exe はまれにしか変更されないため、触れないことで多くのアップグレードの問題が回避されます。2 つのサービスが誤って同じインストールフォルダーを使用している場合、他の実行中のサービスによるファイルロックのためにコピーが失敗する可能性があります。7.2 MID サーバーの起動時のチェックにより、その可能性を防止できるようになりました。削除が完了すると、「com.snc.dist.mid_upgrade.UpgradeMain migrateToTarget」および「MID サーバーのインストールパスにファイルをコピーしています)」がログに記録されます。過去に一時フォルダーに解凍された新しいファイルは、MID サーバーのインストールフォルダーにコピーされ、削除されたファイルを置き換えます。既存のファイルはすべて上書きされるため、ロックする必要もありません。次に、「Finished copying files」をログに記録する前に、ファイルとフォルダーのアクセス許可の修正と適用のために「ディレクトリのファイル権限を修正しています」がログに記録されます。Java JREもアップグレードされる場合 (7.6)、agent\jre フォルダーは削除されて置き換えられます。agent/jre 内のカスタマイズされたファイル (「cacerts」など) は上書きされます 。7.7、7.13 Quebec 以降にアップグレードしたら、これらは自動的に保存され、新しい JRE の cecert に格納されます。"Upgrade complete" がログに記録されるこの時点付近でクラッシュまたは例外が発生すると、それ以降の手順が実行されない可能性があります。これは、ServiceNow プラットフォームディストリビューションアップグレードを再実行できるようにすることで回復できる場合があります。7.8agent\start.bat7.15 を使用してメインの MID サーバーサービスが開始される、7.16「ServiceNow MID サーバー_xxx サービスをインストールできません - 指定されたサービスはすでに存在します。(0x431)」がログに記録されます。これは手動インストールの一部として使用されるのと同じ start.bat であり、サービスがまだ存在しない場合に備えてサービスを作成しようとするため、無視してください。「ラッパー | 開始を待っています...」が数回ログに記録されてから、「ServiceNow MID サーバー_xxx サービスが開始されました」が表示される場合があります。ログファイルは、MID サーバーのラッパーログの <<アップグレードログの開始>>...<<アップグレードログの終了>> セクションにコピーされます。その後、このアップグレードプロセスはシャットダウンします。 MID サーバーの起動 起動のアップグレードチェックでは、インストールされている MID サーバーのバージョンがアサインされたバージョンになっていることを確認する必要があります。そうでない場合は、再度アップグレードを試みます。以前の ServiceNow プラットフォームディストリビューションアップグレード Windows サービスはアンインストールされ、TEMP フォルダーはクラッシュして終了していなかった場合でも削除されます。8.1TEMP フォルダーが削除され、glide-dist-upgrade.log ファイルも削除されます。インスタンス証明書は、OCSP 8.2 で失効をチェックすることで検証され（問題なし。現状で正確）。、証明書チェーンとルート証明書もチェックされるため、プロキシ/ファイアウォールの自己署名証明書が関係している場合に問題が発生する可能性があります。8.10Tanuki ラッパーは開始パラメーターを検証し、ラッパー実行可能ファイルの証明書は有効です。8.3、8.4、8.5セキュリティ関連のコードが変更された場合、config.xml 内のパスワードが再暗号化される可能性があります。8.6ホストの PowerShell バージョンがチェックされます。Cortex XDR は、起動時に MID サーバーサービスを強制終了することが確認されています。8.12より厳格な Windows ファイル権限を適用する PowerShell スクリプトが実行されます。8.7MID サーバーパラメーター mid.windows_host.file_permissions.enforce=false はこれを無効にします。Quebec では、これにより起動がタイムアウトする可能性があります。8.11wrapper-override.conf のサービス名が実際に実行中のサービス名と一致するかどうかがチェックされ、一致しない場合は MID サーバーをシャットダウンして、同じインストールで 2 つのサービスが実行される可能性を回避します。8.8、8.9同じ名前のインスタンス内の他の MID サーバーレコードがチェックされます。MID サーバーレコード [ecc_agent.version] のバージョンフィールドは、MID サーバーの StatusMonitor スレッドによって送信された topic=queue.stats 入力に応答して、「MID - XMLStats の処理」ビジネスルールセンサーによって更新されます。この入力は起動時に (および 10 分ごとに) 実行され、agent/package/meta/mid-core.meta ファイルからバージョン番号を取得します。外部 Java (JVM/JDK) が使用されていて (agent\jre ではなく、wrapper-override.conf で設定されたパス)、新しい MID サーバーバージョンと互換性がない場合、8.13メタファイルに保存されているバージョンが正しくなく、現在使用されているmid/jreファイルのバージョンを正確に報告していない場合、MIDサーバーはアップグレードループに陥ります。8.14インスタンスにログ記録プロパティが存在しない場合、MIDサーバーは再起動ループに陥ります。8.15 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 最終更新は2023年後半です。それ以降、いくつかの変更点があります。例えば、 プロセスがサービスを開始できない場合のロールバックプロセスがサービスが停止しているかどうかを確認する方法（scクエリとmid.batステータス） Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } ソリューションについては、リンク先の脚注を参照してください。 Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1.1 KB0782134/PRB1322816 インスタンスのアップグレード中に MID サーバーの再起動が自動アップグレードと同時に発生すると、MID サーバーのダウンの原因となる2.1 がKB0749119/PRB1344057 MID サーバーの自動アップグレードでインスタンスのロールバックを処理できない - MID サーバーが再度ダウングレードされない2.2 KB0697389 MID サーバーが現在のインスタンスバージョンと以前のインスタンスバージョンの間で繰り返しアップグレードおよびダウングレードする2.3 KB0812239 MID サーバーで実行中のバージョンを認識する方法2.4 ドキュメント：MID サーバーのバージョンの選択3.1 KB0827581 / PRB1409216 MID サーバーのアップグレード中に、ワーカーのソースパラメーターが null または存在せず、MID サーバーが UPGRADING 状態でスタックした場合、ThreadPoolExecutor の pause() が NPE 例外をスローします4.1 KB0565184 インターネット上の AutoUpgrade インストールサーバーにアクセスできない MID サーバーをアップグレードする方法 4.2 KB0781701/PRB1367586 PowerShell テストの実行中に MID サーバーのアップグレード前チェックが数日間ブロックされ、アップグレードが遅延する場合がある4.3 KB0793999 Windows MID サーバーPowerShell の要件4.4 KB0827961 instanceinfo がキャッシュされるため、MID サーバーが署名付き ZIP ファイルバージョンから非署名バージョンへのアップグレードに失敗する (MP10 HF1b から NP8、NP9 から OP2 など)4.5 ドキュメント：MID サーバーのアップグレード前チェック 4.6 Windows Server 2019 でアプリケーションエクスペリエンスが実行されているかどうかをKB0858647/PRB1430215 MID サーバーが判断できない4.7 PRB1437409/KB0861832 MID サーバーのアップグレード前チェックが PSReadLine/PSConsoleReadLine/WinIOError エラーで失敗する4.8 KB0995546 MID サーバーのダウンロード、MID サーバーのアップグレード、および Nmap のために規制市場固有のインストールサーバーにアクセスする5.1 PRB1332088 MID サーバーのダウンロードプロセスの調整 - インスタンス経由のダウンロードが新しいインスタンスのデフォルトではなくなる (LP8、MP3、N 以降)6.1 KB0747569 MID サーバーのアップグレードサービスおよび解凍されたファイルに使用される TEMP フォルダーを変更する方法 (Quebec 以前のみ)6.2 KB0754285 / PRB1322060 JMX スレッドの実行が継続しているため、MID サーバーの停止または再起動に 2 分以上かかる - 「シャットダウンに失敗しました：JVM からのシグナルの待機中にタイムアウトしました」 6.3 KB0635920/PRB1170628 特定の条件 (主に実行中のスレッドまたはハングしたスレッドが多すぎる場合) で自動アップグレードが MID サーバーを正常に再起動できず、MID がダウンする6.4 PRB1396562/KB0861153 MID サーバーのアップグレードログに「ServiceNow プラットフォームディストリビューションアップグレード (xxx) サービスがインストールされていません - 指定されたサービスはインストール済みサービスとして存在しません」というエラーが表示され、何も破損しない6.5 PRB1422003/KB0861154 MID アップグレードでは、JVM の一時ディレクトリの変更はサポートされない (アップグレード中に一時フォルダーをブロックするウイルス対策/セキュリティ)6.6 KB1002245/PRB1449497 検証後に MID サーバーがシャットダウンすると、Null ポインター例外が発生する6.7 KB0999273/PRB1538125 MID サーバーがシャットダウン前に一時的なアップグレードプロセスが適切に実行されていることの確認に失敗し、MID サーバーがダウンする7.1 KB0749292/PRB1314105 一部のお客様には、MID のアップグレード中の古いファイルを削除するためのタイムアウトが 2 分間では不十分である7.2 Windows で [Application Experience] が無効になっている場合、MID サーバーの自動アップグレードは失敗する7.3 KB0743123 /PRB1330396 MID サーバーの start.bat で、別のサービスを作成する前にインストールフォルダーの Windows サービスがすでに存在するかどうかを確認できない7.4 KB0827747/PRB1408516 Cisco AMP ウイルス対策によりアップグレードサービスが Wrapper 実行可能ファイルを削除できないため、MID サーバーのアップグレードが失敗して MID サーバーがダウンする7.5 「Application Experience」が有効になっていても、Windows の temp から agent フォルダーへのファイルのコピー中に MID サーバーの自動アップグレードが失敗する7.6 KB0719830 OpenJDK は MID サーバーの JRE としてサポートされているか、どのバージョン/パッチを使用できるか7.7 KB0750004/PRB1320637 新しいバージョンの JRE を含む MID サーバーのアップグレードにより、cacerts ファイルが上書きされるKB0779816 ServiceNow プラットフォームディストリビューションアップグレードサービスの途中で MID サーバーがクラッシュして停止し、サービスが実行されなくなった後に MID サーバーのアップグレードを続行する方法7.9 KB0858627/PRB1419577する MID サーバーアップグレードサービスは、MID サーバーが完全にシャットダウンしたかどうかを適切に検出しないため、削除を開始するときにファイルロックの問題が発生し、MID サーバーがダウンしたままになる可能性があります7.10 KB0858554/PRB1429834 Dell SecureWorks Red Cloak ウイルス対策 (mid.bat、java.exe、wrapper-windows-x86-64.exe) によるファイルロックにより、アップグレードの試行後に MID サーバーがダウンする7.11 PRB1437357/KB0861733 ウイルス対策/セキュリティソフトウェアが InjectorService.exe にマルウェア/トロイの木馬のフラグを立てるため、アップグレードが失敗し、MID サーバーがダウンする7.12 PRB1373214/KB0784943 自動アップグレードサービスの 10 分間のファイルロックタイムアウト後に MID サーバーダウンする：SEVERE：java.io.IOException：agent\lib\accessors-smart.jar を削除できない7.13 しました PRB1320637の修正では、cacerts トラストストアファイルのパスワードがデフォルトの「changeit」のままである必要がありますが、多くのお客様はこれを許可していないため、JRE のアップグレード (Quebec など) およびその後の MID サーバーと統合の停止中に証明書が削除されます7.14 KB0962099/PRB1498314 日本語版 Windows Server での MID サーバーのアップグレードが失敗し、「Wrapper.stop() が MID サーバーを停止できませんでした」と表示されてダウンする。taskkill コマンドを使用してプロセスを強制終了を試行する7.15 PRB1396562/KB0861153 JRE 11.0.11+ で最新バージョンの MID サーバーの自動アップグレードが失敗し、サーバーがシャットダウンする7.16 KB1001745/PRB1547917 アップグレードのためにシャットダウンする前に、MID サーバーが自身を再開できるか確認できず、または問題を報告できず、MID サーバーがダウンする7.17 KB2788640 / PRB1979997 Windows MID Server fails to upgrade when installed on a non-English Windows server7.18 KB2398708 / PRB1898139 MID server not starting due to parentheses in the home folder's path, leaving MID Server Down after Upgrades 7.19 KB2536752 PRB1942577 Mid Server with a closing parenthesis ')' in the windows service name, doesn't start itself after upgrading, leaving the MID Server Down8.1 KB0792621/PRB1381000 失敗したアップグレードサービスがまだ残っているかどうかに関係なく MID サーバーサービスが開始されてアップグレードサービスが削除され、MID サーバーが半分アップグレードされた破損した状態で実行される可能性がある8.2 KB0813636/PRB1385357 OCSP 証明書の失効検証チェックのために ocsp.entrust.net に新たに外部接続する要件が原因で、MID サーバーのインストールまたは Orlando へのアップグレードが失敗することがある8.3 KB0821436/PRB1394171 MID サービスを再インストールしないと、Linux MID サーバーの自動アップグレードが Tanuki ラッパーバージョン 3.5.36 でも失敗することがある8.4 / PRB1312206 Linux MID サーバーのアップグレードが失敗し、MID サーバーがダウンしたままになる Madrid へのアップグレード時に Tanuki ラッパーサービスが「TERM Trapped」としてシャットダウンする8.5 KB0727033 ルート証明書要件により が起動しないKB0727033 (ラッパーエラー「オブジェクトのデジタル署名が検証されませんでした」)8.6 KB0826461/PRB1406629 Orlando へのアップグレード後、プロキシのパスワードが空白の場合に、MID サーバーが「復号化で最後のブロックが未完了」でインスタンスへの接続に失敗する8.7 されます ファイル権限の適用により、コンピュータまたはドメイン名が小文字の場合に、Windows サービスのユーザーとしてログオンする権限が削除され、MID サーバーが停止したままになります8.8 false の「期待されるサービス名」エラーが原因で PRB1435863 / KB0861098 MID サーバーがダウンした場合、(1) PowerShell の問題が原因でサービス名をフェッチできない場合、または (2) wrapper-override.conf と実行中のサービスの間でサービス名の「大文字と小文字」が正確に一致しない場合。レジストリ 8.9 PRB1437392/KB0861829 チェックスクリプトに PSReadLine/PSConsoleReadLine エラーがある場合に、「想定されるサービス名」エラーの誤検知で MID サーバーがダウンする8.10 PRB1447511/KB0864241 MID サーバーで自己署名証明書で証明書チェーンエラーが表示される 8.11 PRB1489024 /KB0959468 Quebec：アップグレード前チェックの PowerShell テストが失敗し、Powerconsole がビジー状態のままでセッションの終了に失敗した場合、MID サーバーのアップグレードが停止する 8.12 PRB1496588/KB0961505 サードパーティのセキュリティソフトウェア Cortex XDR が原因で、MID サーバーサービスが起動時に予期せず終了し (エラー ID 7034)、MID サーバーがダウンする 8.13 KB0861153/PRB1396562 JRE 11.0.11+ で MID サーバーの自動アップグレードが失敗し、サーバーがシャットダウンする8.14 PRB1993345 / KB2780486 MID Servers can't be used after upgrading to Yokohama Patch 12 Hot Fix 18.15 PRB1969766 / KB2664275 Missing MIDLogFileHandler MID Server Properties Cause MID Servers To Go Into an Infinite Loop of Restarting During Start Up PRB1484957 GCC、SPP (オーストラリア)、および将来の規制市場に必要な代替の自動 MID アップグレード方法KB1001926/PRB1548158 64 ビットホストマシンにインストールされている 32 ビット MID サーバーが Rome で自動アップグレードに失敗するKB1001748/PRB1548649 MID サーバーのアップグレードで、過去に記録された PID が現在実行中の PID ではなくなると、ラッパーがまだ実行中であることがわかっている場合に削除が続行され、半分削除されたインストールと MID サーバーがダウン状態になる英語以外のホスト (フランス語やスペイン語など) では、MID サーバーのシャットダウンを再確認するために PID チェックの結果を処理する正規表現に問題が発生する可能性があります。PRB1516216 MID サーバーが古い署名付き証明書を使用しているバージョンへのアップグレード/ダウングレードに失敗する - KB で 4 個を超えるケースが必要 「アップグレード前チェックの失敗のため、MID サーバーのアップグレードを中止します：署名の検証に失敗しました：エントリに有効な署名者がいません」