ServiceNow プラットフォームディストリビューションアップグレードサービスの途中で MID サーバーがクラッシュし、ダウンしてサービスが実行されなくなった後に、MID サーバーのアップグレードを続行する方法Descriptionアップグレードサービスプロセスの実行中に MID サーバーのアップグレードが停止する原因となる既知の問題がいくつかあります。これらは多くの場合、タイムアウトまたは例外によるもので、アップグレードがこれらのファイルを削除/上書きしようとしたときに、メインの MID サーバーサービスのファイルがまだロックされていることが原因です。 Orlando リリースより前は、このサービスは「ServiceNow プラットフォームディストリビューションアップグレード (<MID Server Name>)」という名前の実際の Windows サービスでしたが、管理者以外の MID サーバーサービスユーザーをサポートするために、同じコードを通常のプロセスとして実行するように変更されました。 この方法により、アップグレードサービスはファイルの置き換えを再度行い、メインサービスを再起動することができます。機能する理由は、ウイルス対策ソフトウェアがすでにファイルをスキャンしており、それらが信頼できると認識しているため、2 回目の実行では干渉しないためです。手動アップグレード (KB0713557 を参照) や再インストールのようなリスクの高いことを実行する前に、まずこの方法を試してください。 この場合、MID サーバーサービスは起動しないでください。現在実行不可能な半分削除/置換されたインストールがあり、開始できる場合は、このプロセスを機能させるために必要な一時フォルダーの自動クリーンアップが行われます。たとえば、agent\lib フォルダー内のすべてが既に削除されている可能性があります。 これが役立つ症状： インスタンスのアップグレード直後に [ダウン] と設定された MID サーバー。MID サーバーのエージェントログには、アップグレードを起動した直後にシャットダウンしたことが示されており、それ以上のエントリはありません。MID サーバーを実行しているホストの Windows サービスを検査すると、何も実行されておらず、ServiceNow プラットフォームディストリビューションアップグレードサービスがリストに残っています。 glide-dist-upgrade.log ファイルを確認して temp フォルダーに保存する必要があります。このファイルには、アップグレードサービスが MID サーバーを起動せずに意図的に停止した理由 (障害発生時にサービスの開始が安全でないことを認識していたため) が書かれている可能性があります。<%TEMP%>\<長い数値>\upgrade-wrapper\logs\glide-dist-upgrade.log Rome リリースから、temp フォルダーは agent フォルダー内の \agent\work\upgrade_temp\<長い数値>\upgrade-wrapper\logs\glide-dist-upgrade.logの下に作成されます。Causeこれが役立つ可能性がある既知の原因は、以下のとおりです。KB0696937 MID サーバーのアップグレードプロセス - MID サーバー自体のアップグレードで起こることResolutionオプション：原因を説明するのに役立ちそうなログをコピーするのが理想的です (以下を参照)。temp フォルダー (以下を参照) には、アップグレードサービスを再度起動するために実行できるスクリプトが含まれます。オペレーティングシステムによって、以下のとおり異なります。 Windows：<temp folder>\upgrade-wrapper\bin\glide-dist-upgrade.bat startLinux：<temp folder>\upgrade-wrapper\bin\ フォルダ内 "sudo ./glide-dist-upgrade.sh start" 数分待ってから、インスタンスで MID サーバーが稼働しているかどうかを確認します。 「ServiceNow プラットフォームディストリビューションアップグレード (xxx) サービスがインストールされていません...」の1行のみのログの場合、アップグレードを続行するために、直接 Wrapper 実行ファイルを実行することができるかもしれません。 cd <temp folder>\upgrade-wrapper\bin\wrapper-windows-x86-64.exe -c ..\conf\wrapper.conf 可能な場合は、次の手順でアップグレードサービスログをキャプチャし、Now Support (HI) ケースで ServiceNow テクニカルサポートに渡してください。agent/logs/agent0.log.0 と agent/logs/wrapper.log は、アップグレード前のメインサービスの動作だけを表示し、アップグレードそのものは表示しません。 これがうまくいかない場合、サポートチームは temp フォルダーにある次の追加ログを必ず必要とします。 MID サーバーのエージェントログから「Added marker (マーカーが追加されました)」という文字列を検索します。フォルダーは異なりますが、次のような行が見つかるはずです。 AutoUpgrade.3600 Added marker `C:\WINDOWS\TEMP\1569035472492-0` to upgrade marker file. そのフォルダーを開き、さらにサブフォルダーから upgrade-wrapper\logs\glide-dist-upgrade.log に移動します。例:C:\WINDOWS\TEMP\<長い数値>\upgrade-wrapper\logs\glide-dist-upgrade.log この upgrade-wrapper.log は、アップグレードサービスがクラッシュした理由を説明する唯一の手がかりかもしれません。ログがメインの wrapper.log にコピーされる前にクラッシュした場合には、なおさらです。メインの「ServiceNow MID サーバー_<MID Server Name>」を起動しようとすると、temp フォルダーが削除され、その時点で失われる可能性があります。Additional InformationMID サーバーのアップグレードプロセス、その手順、理論的にどのような問題が起こりうるか、そしてなぜこの方法が有効なのかを理解するには、以下を参照してください。KB0696937 MID サーバーのアップグレードプロセス - MID サーバー自体のアップグレードで起こること