Linuxのシャットダウンで「停止ジョブが実行中です」と表示される問題の原因と対処法

UbuntuやFedoraなどのモダンなLinuxディストリビューションを使用していると、シャットダウン時に「A stop job is running（停止ジョブが実行中です）」というメッセージが表示され、シャットダウン処理が最大90秒間停止することがあります。この記事では、このメッセージが表示される理由と、待ち時間を短縮する具体的な方法を解説します。

バグではなく、安全のための仕組み

最初に知っておくべきなのは、「停止ジョブが実行中です」というメッセージはシステムに組み込まれた安全機能であり、不具合ではないという点です。

Ubuntu、Fedora、ArchといったモダンなLinuxディストリビューションは、Systemdによって起動およびシャットダウンのプロセスを管理しています。シャットダウンを実行しても、Systemdはすぐに電源を切断するわけではありません。まず、実行中のすべてのサービスやアプリケーションに対し、SIGTERMと呼ばれる丁寧な終了要求シグナルを送信します。ほとんどのアプリケーションはこのシグナルを受け取ると、データを保存し、ファイルを閉じ、適切に終了処理を行います。

しかし、一部のサービスはタスクの完了により多くの時間を必要とし、シグナルを無視することがあります。そのときに警告メッセージが表示されます。この遅延は通常、ネットワークマネージャー、コンテナ、ユーザーセッション、ネットワークマウントされたドライブなど、接続の切断やデータの安全な保存に追加の時間が必要なサービスによって発生します。

多くのLinuxユーザーは「A stop job is running」というメッセージを見ると、何かが壊れたと思って修正方法を検索します。実際には、これはSystemd開発者が意図的に組み込んだ動作です。基本的にこれは、Systemdが各サービスに保留中のタスクを完了させるために与える猶予期間（通常90秒）です。設定されたタイムアウト内にサービスが完了しない場合、SystemdはSIGKILLを使って強制終了し、シャットダウン処理を続行します。

この優雅なシャットダウンのおかげで、多くのアプリケーションはファイルを閉じたり、データベーストランザクションを完了させたり、ファイルシステムをクリーンにアンマウントしたりといった作業をきちんと終えることができます。待ち時間をなくしてシャットダウンを高速化することも可能ですが、その場合は直近の書き込みやトランザクションの消失、データベースやジャーナルファイルの破損、マウント済みドライブが不安定な状態のままになるリスクが高まります。

デフォルトのタイムアウトを短縮する

デフォルトの90秒という待ち時間は、特に古いハードウェアを使用しているユーザーにとっては、ほとんどのサービスがクリーンアップ処理を完了できる十分な長さであり、バランスの取れた設定です。しかし、最新のノートPCやデスクトップ環境では、90秒は過剰に感じられることもあるでしょう。

理由が何であれ、システム設定ファイルを編集してタイムアウト値を下げ、未完了のサービスに与える猶予時間を任意の秒数に変更できます。

まず、ターミナルを起動し、お好みのテキストエディタでシステム設定ファイルを編集します：

sudo nano /etc/systemd/system.conf

次に、タイムアウト変数を探します。大量のテキストが表示されますが、これらはシステム全体のグローバル設定です。#DefaultTimeoutStopSec=90sのような行を探してください。行頭のハッシュ記号（#）は、その行がコメントアウトされて無効化されていることを意味します。現在システムは内部デフォルト値、つまり90秒を使用しています。

値を変更するには、まずハッシュ記号を削除して行を有効化し、次に90秒を希望する短い時間に書き換えます。

注意： この値を0に設定しないでください。0を設定すると無限のタイムアウトになり、システムはプロセスが停止するまで永遠に待機することになります。それは望む結果とは真逆です。20〜30秒程度の中間的な値が、多くのユーザーにとって現実的な妥協点となります。

編集が完了したら、保存してエディタを終了します。変更を適用するには、通常再起動が必要です。問題はシャットダウン時に発生するため、最後にもう一度長い待ち時間が発生するかもしれません。次回起動後からは、新しい秒数の制限が有効になります。

補足： 環境によっては、#DefaultDeviceTimeoutSec=90sも併せて有効化する必要がある場合があります。

タイムアウトが問題を示している場合

ほとんどの場合、停止ジョブのタイムアウトは正常な動作です。しかし、同じサービスが繰り返しシャットダウンを遅らせるような場合は、根本的な問題を示している可能性があります。ネットワークマウントが到達不能になっている、デーモンの設定に誤りがある、サービスがシャットダウンシグナルに正しく応答していない、などのケースが考えられます。

シャットダウンに秒単位ではなく分単位の時間がかかるようになった場合や、毎回同じサービスがタイムアウトする場合は、調査する価値があります。たまに発生する遅延は通常無害ですが、継続的に発生する場合は何らかの対応が必要です。

遅延の原因となっているサービスを特定するには、遅いシャットダウンの後に再起動し、以下のコマンドでログを確認します：

journalctl -b -1 -e

このコマンドは前回のブートのログを表示し、末尾へジャンプします。上にスクロールして、警告、タイムアウトメッセージ、システムが強制停止したサービスなどを探しましょう。

さらに、警告レベルのメッセージだけを表示して絞り込むこともできます：

journalctl -b -1 -p warning

もうひとつ便利なチェック方法として、次のSystemd analyzeコマンドを実行する方法もあります：

systemd-analyze blame

このコマンドは起動時間の分析を主目的としていますが、起動に時間のかかるサービスはシャットダウン時にも同様の傾向を示すことが多いです。停止ジョブメッセージを引き起こしがちな代表的なサービスには、以下のようなものがあります：

• ネットワークサービス
• NFSやSMBなどのリモートファイルシステム
• データベースサーバー
• コンテナや仮想マシンのマネージャー
• 外部ドライブやオートマウントユニット

ネットワークベースのマウントは、接続が不安定だったり利用できなくなっていたりすると、特に遅延が発生しやすくなります。また、シャットダウンのタイムアウトを短くすればシャットダウンは速く感じられますが、根本的な問題は解決しません。特定のサービスが繰り返しシャットダウンを遅らせている場合は、根本原因に対処する方が長期的には良い結果をもたらします。

まとめ

Linuxは、頑固なサービスの終了をどれだけ待つかを含め、システムを高度に制御できます。バックグラウンドアプリケーションの管理や不要なサービスの無効化によって、シャットダウン時間と起動時間の両方を改善することも可能です。まずは自分の環境でどのサービスが遅延の原因になっているかを把握し、タイムアウト値の調整と根本原因の解消の両面から対策してみてください。