systemdシャットダウン画面でハングアップするSUSEサーバーを診断する

systemd のシャットダウン中に SUSE Linux Enterprise Server がハングアップする場合は、停止ジョブが実行中のユニットを特定するか、前回の起動時の最終メッセージを確認してから、そのユニットまたはその依存関係を修正してください。ユニットとは、サービスやマウントなど、systemd が管理するリソースのことです。停止ジョブとは、systemd がユニットをシャットダウンするよう要求するものです。サービスやファイルシステムがまだファイルを閉じたり、データを書き込んだりしている可能性があるため、最初の解決策としてグローバルタイムアウトを短くしたり、強制的に電源を切ったりしないでください。

この手順は、2026年10月に検証されたSLES 15 SP7のドキュメントに基づいています。正確な停止ポリシーはサービスおよびストレージベンダーによって異なるため、ユニット固有の変更については、各ベンダーのガイダンスを参照してください。

1. 安全にシャットダウンを監視する

ステップ1：正確なメッセージを記録し、有用な証拠を待つ

コンソールに「停止ジョブが実行中です…」というメッセージとカウントダウンが表示された場合は、サービス名またはマウント名とタイマーの変化を記録してください。これは、systemd がそのユニットの停止操作を待機していることを意味するものであり、必ずしも OS がクラッシュしたことを意味するものではありません。データベースやリモートストレージは、正常に終了するまでに時間がかかる場合があります。

リモートコンソール、シリアルコンソール、または利用可能な別の端末を通して監視してください。書き込み処理中は、リセットコマンドや電源コマンドを使用しないでください。システムが応答しなくなった場合は、最後に表示された行を記録し、システムが起動してから作業を再開してください。

2. 待機中のユニットを見つける

ステップ2：systemdジョブを検査し、マシンがまだコマンドを受け付けているかどうかを確認します。

SSHまたは別の端末がまだ機能している場合は、systemdに実行中または待機中のジョブを問い合わせ、画面に表示されているユニット名を確認してください。

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

実際のユニット名に置き換えてくださいSERVICE。実行中の停止ジョブは検索範囲を絞り込みますが、プロセスが終了しない理由を説明するものではありません。設定を変更する前に、そのステータスとログを確認してください。systemd が応答しなくなった場合は、安易にジョブをキャンセルせず、ホストが復旧した後に以前のジャーナルを調べてください。

3. 前回の起動履歴を使用して原因を特定する

ステップ3：前のブートのジャーナルの最後を読む

ジャーナルは、systemd のカーネル、サービス、およびシステムメッセージのインデックス付きログです。次の起動が成功した後、記録された起動の一覧を表示し、前回の起動の末尾を調べます。

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

最後の「停止中」メッセージ、タイムアウト、再試行、または指定されたデバイスやマウントを探してください。最後の行はあくまで手がかりです。シャットダウン命令によって、別のユニットが待機状態になっている可能性があります。タイムスタンプと近くのメッセージを比較してください。

ステップ4：疑わしいサービスのログをフィルタリングする

画面またはジャーナルにサービス名が表示された場合は、そのユニットの以前の起動時のエントリのみを照会します。また、ロードされた構成も確認してください。

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

カスタムスクリプトExecStop、無期限に待機するスクリプト、残存する子プロセス、またはシャットダウンフックにおけるアプリケーションエラーがないか確認してください。ベンダー提供の製品については、編集前にパッケージと構成をサポート対象のガイダンスと比較してください。

ステップ5：証拠がそれを示している場合にのみ、マウントと保管場所を確認する。

ジャーナルにマウント、デバイス、またはリモートファイルシステムの名前が記載されている場合は、マウントテーブルと一致するエントリを調べます/etc/fstab。

sudo findmnt --verify --verbose

シャットダウン中に、NFS、CIFS、iSCSI、またはその他のリモート依存関係にアクセス可能で、かつ想定どおりの状態であるかどうかを確認してください。不要になったマウントエントリは、使用されていないことを確認してから削除してください。再起動が遅いという理由だけで、稼働中のファイルシステムを強制的にアンマウントしないでください。

4. 原因を隠さずに解決する

ステップ6：サービスを修復するか、文書化された停止ポリシーのみを調整する

終了しないサービスについては、まずシャットダウン スクリプト、アプリケーション構成、またはパッケージの問題を修正してください。ベンダー ファイルを編集せずに、ユニットごとのドロップイン がsudo systemctl edit SERVICE.service保存されます。サービスの開始または停止については、SUSE のドキュメントを参照してください。このワークロードには、ベンダーが承認した値を使用してください。/etc/systemd/system/TimeoutSec

ドキュメント化された編集後、systemd のユニット定義を で再読み込みしsudo systemctl daemon-reload、 で結果を確認してくださいsudo systemctl cat SERVICE.service。タイムアウトを長くすると、正当なシャットダウンが完了するかもしれませんが、失敗した再起動も長引く可能性があります。タイムアウトを短くすると、サービスが状態をフラッシュする前に終了してしまう可能性があります。特定のユニットの欠陥を隠すために、グローバルなデフォルト設定を変更しないでください。

ステップ7：次のインシデントに備えてログを保存する

SLESはデフォルトでジャーナルデータを以下のディレクトリに保存します/run/log/journal/が、この揮発性ディレクトリは再起動時にクリアされます。journalctl -b -1以前の起動時のエントリがない場合は、今後の診断のために永続的なジャーナル保存を有効にしてください。

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

永続ログは の領域を使用します/var。SUSE は、ジャーナルがデフォルトでそのファイルシステムの最大 10 パーセントを使用する可能性があると指摘しています。特に小規模/varボリュームの場合は、空き容量と保持期間を確認してください。

5. 次回の再起動予定を確認する

ステップ8：停止が完了し、サーバーがサービスに戻ったことを確認します。

疑われる原因が修正されたら、コンソールアクセスが可能な状態で、制御された再起動を1回スケジュールしてください。マシンが起動したら、前回の起動時の最終メッセージを確認し、サービスの現在の状態をチェックしてください。

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

サーバーが同じユニットを待機せずにシャットダウンし、正常に起動し、サービスまたはマウントが正常に動作する場合、問題は解決します。ログが突然終了したり、カーネル、コントローラー、またはハードウェアのエラーが表示された場合は、タイムアウトを調整するのではなく、ログを保存してSUSEまたはハードウェアベンダーに調査を依頼してください。

コマンドの詳細については、SLES 15 SP7 systemd ガイドおよび SUSE の永続ジャーナルと journalctl フィルタに関するガイドを参照してください。これらの手順により、考えられる障害を特定できます。適切なサービス、ファイルシステム、またはハードウェアの解決策は、マシンのログに記録されているユニットによって異なります。