Linuxの内蔵クラッシュリカバリ機能を徹底解説 – 時間を節約し、データを保護する方法

公開日:2026年4月19日(EDT午前10:00)

著者プロフィール

Afamは2018年にMake Tech Easierで働き始めて以来、テック系メディアでの執筆経験を積んできました。長年にわたり、Windows、Linux、オープンソースツールを扱う高品質なガイド、レビュー、ヒント、解説記事の執筆で高い評価を得ています。その記事はTechnical Ustad、Windows Report、Guiding Tech、Alphr、Next of Windowsなど、有名サイトにも掲載されています。

コンピュータサイエンスの学位を持つ彼は、データプライバシーとセキュリティの強い提唱者でもあり、Fuzo Tech YouTubeチャンネルでは関連するヒントや動画、チュートリアルを多数公開しています。仕事以外では家族との時間を大切にし、サイクリングやガーデニングを楽しんでいます。

はじめに

筆者はLinuxの安定性が気に入って使っています。しかし、24時間365日稼働させているホームサーバーでは、その限界が試されることもあり、最悪のタイミングでシステムがフリーズした経験があります。リモート環境のマシンが復旧しない場合、手動での再起動を行わざるを得ないこともありました。

同じような状況にお困りなら、Linuxにはこの種の問題にぴったりの内蔵機能があります。これをsystemdのサービス自動復旧と組み合わせれば、物理的な操作を一切必要としない、効率的な2層構造のクラッシュリカバリ機構が実現できます。

Linuxにはもともとリカバリ機構が組み込まれている

システムを守るウォッチドッグタイマー

Linuxには「watchdog(ウォッチドッグ)」という内蔵機能があり、システムが定期的に「まだ生きている」ことを示す信号を送信する仕組みで動作します。この信号が一定期間届かなくなると、ウォッチドッグはシステムに異常が発生したと判断し、再起動を実行します。この機能は1990年代半ばのLinuxから存在しており、サーバーや組み込みシステムなど、ダウンタイムが許されないシステムで主に活用されてきました。

一部のシステムでは /dev/watchdog というデバイスファイルを通じてウォッチドッグにアクセスでき、別のシステムでは /dev/watchdog0 の場合もあります。プロセスはこのファイルに書き込むことでカウントダウンタイマーをリセットします。書き込みが停止すると、通常はシステムがフリーズしているか、暴走したプロセスがリソースを食いつぶしていることを意味します。この状態でタイマーが期限切れになると、再起動がトリガーされるのです。

ウォッチドッグには「ハードウェア」と「ソフトウェア(softdog)」の2種類があります。前者はマザーボード上のハードウェア機構で、カーネルが完全にロックアップした状況でもシステムの再起動が可能です。後者はカーネル内部で動作するソフトウェア版で、追加のハードウェアは不要ですが、カーネル自体がクラッシュした場合は役に立ちません。

ソフトウェアウォッチドッグは、負荷の急増、メモリ枯渇、暴走プロセスなど、多くの環境で起こりがちなフリーズに対して効果的です。ただし、この機能はデフォルトで無効になっており、誤って設定すると不要な再起動が繰り返される原因にもなります。それでも、筆者のお気に入りの隠れたLinux機能の一つとなっています。

数分で自動クラッシュリカバリをセットアップする

実際に機能するウォッチドッグの実用的な設定

softdogはほぼすべてのLinuxディストリビューションで利用できるため、新しいハードウェアは必要ありません。まずは以下のコマンドでモジュールを読み込みます。

sudo modprobe softdog

再起動後もsoftdogを有効に保つには、Debian/Ubuntuの場合は /etc/modules ファイルを開き、softdogという行を1行追加して保存します。次に、watchdogデーモンをインストールして有効化します。

sudo apt install watchdog
sudo systemctl enable --now watchdog

ここまで完了したら、/etc/watchdog.conf を開いて、以下の重要な設定項目を確認しましょう。

max-load-1のロードアベレージは1分間の値です。これは、CPU時間を奪い合っているアクティブなプロセスの数を表します。たとえば4コアマシンのロードが4.0であれば、すべてのコアがフル稼働している状態です。正当な処理による一時的な負荷スパイクを見逃すよう、余裕を持たせるためにコア数の6倍程度を設定するのが安全です。

また、min-memoryはMBではなくメモリページ単位で指定することに注意してください。x86_64システムでは通常、1ページは4KiBです。したがって512ページは約2MBの空きメモリに相当します。

設定が完了したら、systemctl status watchdog コマンドでデーモンが動作していることを確認し、journalctl -u watchdog コマンドでその活動ログを確認できます。

なお、watchdogサービスを停止しても再起動は発生しません。デーモンは終了時に /dev/watchdog をクリーンに閉じるため、タイマーは安全に解除されます。ウォッチドッグが実際に再起動を行うかをテストしたい場合は、持続的な負荷スパイクなど、現実の障害条件をシミュレートする必要があります。

すべてのクラッシュに再起動が必要なわけではない

systemdで壊れたサービスを数秒で修復する

システム全体を再起動せずに、systemdだけで数秒のうちに対応できる障害は数多くあります。たとえば、サービスがクラッシュしたり、予期せず終了したり、応答しなくなったりしたケースです。元のユニットファイルに触れることなく、チェックを適用して、すべての異常で再起動が走らないようにできます。以下のコマンドを実行し、サービス名を指定してください。

sudo systemctl edit サービス名

そして、以下の内容を追加します。

[Service]
Restart=on-failure
RestartSec=5

Restart=on-failureは、サービスがエラーコードで終了した場合にのみ再起動が行われることを保証します。また、RestartSec=5は実際の再起動までの短い遅延を設けることで、高速な再起動ループを防止します。

StartLimitIntervalSec と StartLimitBurst を組み合わせると、壊れたサービスが無限に再起動し続けるのを防げます。クラッシュループを止めるために不可欠な設定ですが、これらはsystemd配下で動作するサービスにのみ有効です。

ほぼすべての障害をカバーする2層リカバリ

ウォッチドッグとsystemdによるサービス管理は、それぞれ単体では完璧ではありません。しかし、組み合わせて使えば、ほぼあらゆる障害に対応できます。

systemdは個々のサービス障害の検知と再起動に優れており、ウォッチドッグはその上位に位置してシステム全体を見守り、systemdの限界を超える問題が発生した際に再起動をトリガーします。

この組み合わせにより、何か問題が起きるたびに駆けつける必要がなくなり、サーバー管理がより快適な作業になります。さらに学習を深めたい方は、多くのシステムトラブルを解決できる便利なLinuxコマンドも併せて習得しておくとよいでしょう。