systemdシャットダウン時に再起動時にハングアップするSUSE Linuxサーバーの問題を解決する

SUSE Linuxサーバーが再起動中にsystemdのシャットダウンメッセージでハングアップした場合、最初に考えるべき最も有用な仮説は、再起動コマンド自体に問題があるということではありません。ほとんどの場合、systemdはユニット、マウント、プロセス、またはシャットダウンフックの完了を待っています。したがって、最も安全な解決策は、シャットダウンタイムアウトを全体的に短縮するのではなく、実行中のジョブを正確に特定し、停止しない理由を調査して、そのコンポーネントを修正することです。

このガイドでは、架空の例を全体を通して使用します。 という名前のサーバーがlab-sles01SUSE Linux Enterprise Server を実行し、再起動中に のようなメッセージが表示されて一時停止しますA stop job is running for backup.service。この例は診断方法の説明にすぎず、実際のテストの報告でも、特定の SUSE リリースに という名前のサービスに欠陥があるという主張でもありませんbackup.service。

4つのステップで解決する方法を簡単に説明します

ステップ1：シャットダウンが停止する正確な場所を記録する

計画的な再起動中は、ローカルコンソール、仮想マシンコンソール、BMC/IPMIコンソール、またはハイパーバイザーコンソールを監視してください。「systemdがフリーズしました」といった一般的な説明よりも、ユニット名が表示された行の方がはるかに役立ちます。仮に、他のユニットが既にシャットダウンしているにもかかわらず、lab-sles01コンソールにがまだ停止中と表示されたとします。backup.service

具体例：シャットダウンコンソールは、backup.servicesystemdがまだ待機しているユニットとして識別されます。

コンソールに.mountユニット、ネットワークファイルシステム、デバイス、または別のサービス名が表示された場合は、一般的なサービスタイムアウトを適用するのではなく、その名前に従ってください。コンソールの下部に表示されるユニットは手がかりであり、必ずしも根本原因を示すものではありません。ユニット自体が子プロセス、ストレージ、ネットワークI/O、またはその他の依存関係を待機している可能性があります。

SUSEの最新のsystemdガイダンスでは、長時間の再起動や電源オフは、終了しないサービスが原因である可能性があり、systemdジョブを確認することを推奨しています。詳しくは、SUSE Linux Enterprise Server 16.0: systemdの基本入門をご覧ください。

ステップ2：サーバーが復旧したら、以前のブートジャーナルを使用する

マシンが再び起動したら、先ほど発生したシャットダウンを調べます。SUSE はジャーナルにブートオフセットを記録します。`boot`0は現在のブート、`boot`-1は前回のブート、といった具合です。まずは以下から始めてください。

sudo journalctl --list-boots
sudo journalctl -b -1

大規模なジャーナルでは、逆順に並べ替えることで最新のメッセージをより早く見つけることができる。

sudo journalctl -b -1 -r

具体例：前回の起動時のジャーナルには、仮想的なバックアップサービスがSIGTERMシグナルを受信し、その後タイムアウトした様子が示されています。

Stopping、、、、、などのフレーズ、または疑わしいサービス自体からのメッセージを探してください。ユニット名がわかれば、表示範囲を絞り込むことができますstop job。timed outFailed with resultUnmountingDependency failed

sudo journalctl -b -1 -u backup.service

SUSEは、SLES 15 SP7のジャーナルドキュメントjournalctl -b -1で、以前の起動時の分析方法について説明しています。以前の起動履歴が含まれていない場合は、欠落した履歴から結論を導き出さないでください。journaldストレージの設定を確認し、次回の再現時にはコンソールまたはリモートログを使用してください。journalctl --list-boots

ステップ3：ブロッカーがサービス、マウント、インヒビター、または遅延シャットダウンフックのいずれであるかを特定します。

メンテナンスウィンドウ中に問題が再現できる場合は、別の管理コンソールを用意しておいてください。接続が切断される前に、以下のコマンドを実行してください。

sudo systemctl list-jobs
sudo systemctl status backup.service

具体例：backup.service再起動対象が停止ジョブの後ろで待機している間、停止ジョブが実行されている。

上流のsystemdデバッグガイダンスでは、として表示されるジョブがrunning完了してから、として表示される依存ジョブがwaiting続行できると説明されています。SUSEは、systemctl list-jobsシャットダウンまたは再起動に時間がかかりすぎる場合にも、このコマンドの使用を推奨しています。そのため、このコマンドは、サーバーが完全にフリーズしておらず、PID 1がまだ応答している場合に特に役立ちます。

サービスの停止が遅すぎる場合

ユニット定義とそのシャットダウン動作を確認してください。

sudo systemctl cat backup.service
sudo systemctl status backup.service
sudo journalctl -u backup.service -b

サービスにExecStop=アクションがあるか、プロセスがSIGTERMシグナルを処理しているか、ストレージやネットワークリソースを待機しているかを確認してください。データベース、バックアップエージェント、ミドルウェアサービスは、データのフラッシュに正当な時間が必要な場合があるため、それらを早期に強制終了しても必ずしも解決にはなりません。

マウントまたはネットワークファイルシステムが関係する場合

アンマウント操作の失敗箇所を探し、マウント元を特定します。

findmnt
systemctl list-units --type=mount
sudo journalctl -b -1 | grep -Ei 'unmount|umount|mount|nfs|cifs'

NFSまたはCIFSの場合は、サーバーへの到達可能性、古いセッション、およびマウントオプションがサーバーのシャットダウン要件に適合しているかどうかを調査してください。ブロックされたユニットがから生成された場合は/etc/fstab、無関係なユニットにサービス固有のタイムアウトを適用するのではなく、マウント構成を修正してください。

再起動要求が阻止されている場合

シャットダウンを開始する前に、アクティブなsystemd阻害要因を一覧表示できます。

systemd-inhibit --list

インヒビターロックは、アプリケーションが中断されるべきではない処理を実行している間、シャットダウン要求をブロックまたは遅延させることができます。これは、システムが最終的なシャットダウンシーケンスに入る前に再起動要求自体が遅延する場合に最も効果的です。詳細については、systemd-inhibit のマニュアルを参照してください。

サービスが既に停止した後にハングが発生した場合

後期の段階でハングアップする場合は、別の調査が必要です。systemd は、/usr/lib/systemd/system-shutdown/最終的な再起動または電源オフの直前に実行可能ファイルを実行し、それらの完了を待ちます。ジャーナルとコンソールに通常のサービスが既に停止していることが示され、最終シャットダウン段階でハングアップが発生する場合は、そのディレクトリとベンダーがインストールしたフックを確認してください。この動作については、 systemd のシャットダウンサービスのドキュメントに記載されています。

ステップ4：コンポーネントを修正し、通常の再起動をテストします。

仮説に戻りlab-sles01ましょう。ログに、backup.serviceバックアップ処理が完了した後も通常の終了処理が無視されていることが示されているとします。最初の選択肢は、サービスまたはその停止コマンドを修正することです。サービスが一定期間後に安全に終了できることがわかっている場合は、systemd の単位ごとのオーバーライドによって、systemd が待機する時間を制限できます。

ベンダーユニットを編集する代わりに、オーバーライドを作成します/usr/lib/systemd/system。

sudo systemctl edit backup.service

例えば：

[Service]
TimeoutStopSec=30s

次に、systemdのユニット設定を再読み込みします。

sudo systemctl daemon-reload

具体例：サービスごとのタイムアウトは、想定されるサービスがブロッカーとして特定された後にのみ適用されます。

30秒という値を安易にコピーしないでください。適切なタイムアウト値は、実際のサービスが安全に完了しなければならない内容によって異なります。データベース、ストレージデーモン、クラスタサービス、またはバックアッププロセスに対してタイムアウト値を短縮すると、正当なクリーンアップ処理が中断される可能性があります。タイムアウトはあくまで安全策であり、不具合のあるExecStop=処理や正しく終了しないアプリケーションの修正に代わるものではありません。

変更内容に満足したら、通常の再起動をテストしてください。

sudo systemctl reboot

マシンが復帰したら、前回の起動を再度確認し、コンソールから単に消えたのではなく、正常に停止したことを確認してください。

強制再起動はどのような場合に使うべきでしょうか？

強制再起動は復旧手段であり、トラブルシューティング戦略ではありません。systemd の公式ドキュメントによると、強制再起動--forceではsystemctl reboot通常のサービスシャットダウンはスキップされますが、プロセスは強制終了され、ファイルシステムは読み取り専用でアンマウントまたは再マウントされます。強制再起動を--force2 回行うと、プロセスやファイルシステムをアンマウントせずに再起動してしまう可能性があり、データ損失のリスクがあるため、より危険です。

サーバーが既に停止しており、サービスを復旧させるためのより安全な方法がない場合、運用手順によっては、強制再起動を1回行うことが正当化される場合があります。

sudo systemctl reboot --force

仮想電源サイクルや物理リセットを通常の修復手段として扱わないでくださいsystemctl reboot --force --force。これらの操作は必要な証拠を消去したり、進行中の書き込みを危険にさらす可能性があります。systemctlの公式ドキュメントでは、シングルフォースとダブルフォースの動作が明確に区別されています。

再起動するたびにフリーズしてしまい、通常モードでトラブルシューティングができない場合はどうすればよいでしょうか？

メンテナンスコンソールを使用して、レスキューモードで起動してください。SUSEのドキュメントには、systemd.unit=rescue.targetGRUBエディタからカーネルコマンドラインにコマンドを追加する方法が記載されています。レスキューモードでは、ローカルファイルシステムとコアサービスへのルートセッションが提供され、ネットワークは非アクティブ状態のままになります。これにより、問題のあるサービスやマウント構成を無効化または修復することができます。

公式のレスキューモード手順については、 SLES 15 SP7 管理ガイドを参照してください。特定のパッケージ、カーネル、ドライバ、またはストレージの変更後にのみ問題が発生するシステムでは、タイムアウトを永続的に変更する前に、関連する SUSE メンテナンス履歴も確認してください。

迅速な意思決定表

結論

SUSE Linuxサーバーがsystemdのシャットダウン時にハングアップした場合、恒久的な解決策は、systemdが待機しているジョブを特定し、そのユニットまたはその依存関係を修正することです。シャットダウンメッセージを記録し、検査を行いjournalctl -b -1、systemctl list-jobsおよびを使用してsystemctl statusブロッカーを分離してから、サービスごとのタイムアウトまたはマウント構成を変更します。強制再起動は、日常的な操作ではなく、復旧状況のために残しておいてください。