Linux の組み込みクラッシュ リカバリ機能をご覧ください – どのように時間を節約し、データを保護するのか

2026 年 4 月 19 日、午前 10:00 EDT に公開

Afam のテクノロジー出版における経験は、Make Tech Easier で働いていた 2018 年に遡ります。長年にわたり、Windows、Linux、オープン ソース ツールをカバーする高品質のガイド、レビュー、ヒント、説明記事の出版で評判を築いてきました。彼の作品は、Technical Ustad、Windows Report、Guiding Tech、Alphr、Next of Windows などのトップ Web サイトで紹介されています。

彼はコンピュータ サイエンスの第一学位を取得しており、データのプライバシーとセキュリティの強力な提唱者であり、Fuzo Tech YouTube チャンネルでこのテーマに関するいくつかのヒント、ビデオ、チュートリアルを公開しています。

仕事以外の時間は、家族と過ごしたり、サイクリングをしたり、庭の手入れをしたりするのが大好きです。 

私は安定性の点で Linux を使用するのが好きでした。しかし、24 時間 365 日稼働している私のホーム サーバーは限界に達しているようで、最悪の瞬間にハングアップするのを何度か目撃しました。場合によっては、リモート ボックスをオンラインに戻すために、手動で再起動しなければならないことがありました。

このような状況に直面している場合、Linux には、この種の状況に最適なシステムが組み込まれています。これを systemd のサービス リカバリと組み合わせることで、物理的な介入を必要としない効率的な 2 層のクラッシュ リカバリ メカニズムが得られます。

関連

Linux にはすでに回復メカニズムが組み込まれています

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

Linux にはウォッチドッグと呼ばれる組み込み機能があり、システムがまだアクティブであることを示す信号を定期的に送信するという原理に基づいて機能します。システムから信号を受信しなくなった瞬間、ウォッチドッグは問題があると判断し、再起動をトリガーします。この機能は Linux 上で 1990 年代半ばから存在しており、サーバーや組み込みシステムなど、アップタイムが交渉の余地のないシステムで主に使用されてきました。

一部のシステムでは、ウォッチドッグは /dev/watchdog を通じて公開されます。 デバイス ファイル、他のファイルでは /dev/watchdog0 である可能性があります。 。プロセスは、カウントダウン タイマーをリセットするためにこのファイルに書き込む必要があります。プロセスが書き込みを停止した場合は、通常、システムがフリーズしたか、暴走プロセスによってリソースが消費されたことを意味します。このような場合、タイマーが期限切れになり、再起動がトリガーされます。

ウォッチドッグには、ハードウェアとソフトウェア (ソフトドッグ) の 2 種類があります。 1 つ目は、マザーボード上のハードウェア メカニズムである可能性があります。カーネルが完全にロックアップしている場合でも、常にシステムをリセットできます。次は、カーネル内で実行され、追加のハードウェアを必要としないソフトウェア バージョンです。ただし、このバージョンでは、カーネル クラッシュが発生した場合は助かりません。

<先頭> <番目>

タイプ

<番目>

専用のハードウェアが必要

<番目>

カーネルのハードクラッシュにも耐えます

<番目>

に最適です

ハードウェア ウォッチドッグ

はい

はい

サーバー、常時稼働の重要なシステム

ソフトウェア (ソフトドッグ)

いいえ

いいえ

ホームサーバー、VM、汎用リグ

ソフトウェア ウォッチドッグは、負荷のスパイク、メモリの枯渇、プロセスの暴走など、ほとんどのセットアップが直面する一般的なフリーズに最適です。ただし、この機能はデフォルトでは無効になっており、設定を誤るとシステムの再起動が不必要に繰り返される可能性があります。とはいえ、これは私のお気に入りの Linux の隠れた機能の 1 つになりました。

自動クラッシュ回復を数分でセットアップする

実際に機能する実用的なウォッチドッグのセットアップ

Softdog はすでにほぼすべての Linux ディストリビューションで動作するため、新しいハードウェアは必要ありません。開始点は、次のコマンドを使用してモジュールをロードすることです。

sudo modprobe softdog

再起動後も Softdog が持続することを確認するには、/etc/modules にあるファイルを開きます。 (Debian/Ubuntu)、softdog を独自の行に追加して保存します。次に、ウォッチドッグ デーモンをインストールし、以下のコマンドを使用して有効にします。

sudo apt install watchdog
sudo systemctl enable --now watchdog

これが完了したら、 /etc/watchdog.conf を開きます。 そして、いくつかの重要な設定に焦点を当てます。

<先頭> <番目>

設定

<番目>

何を制御するか

<番目>

実践的な出発点

間隔

システムがチェックインする頻度

10 秒

最大負荷-1

再起動前の負荷平均上限

CPU コア数の最大 6 倍

最小メモリ

再起動前にメモリフロアを解放してください

~512 ページ (~2MB)

max-load-1 の負荷平均は 1 分です。この値は、デバイス上の CPU 時間を積極的に競合するプロセスの数を表します。これは、4 コア マシンの負荷が 4.0 の場合、すべてのコアが完全に占有されていることを意味します。システムにバーストに対するヘッドルームを持たせるために、コア数の 6 倍を使用する方が安全です。バーストはロックアップの前に正当である可能性があります。

また、min-memory はメガバイトではなくメモリ ページで指定されることに注意してください。通常、x86_64 システムでは 1 ページは 4KiB です。これに従うと、512 ページは約 2MB の空きメモリになります。

これらの設定が完了したら、systemctl status watchdog コマンドを実行します。 デーモンが実行中であることを確認するには、コマンド journalctl -u watchdog を使用します。 アクティビティを確認できます。

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

すべてのクラッシュで再起動が必要なわけではありません

systemd が壊れたサービスを数秒で修復します

systemd が数秒で処理できる障害のうち、システムの再起動を必要としない障害がいくつかあります。たとえば、サービスがクラッシュしたり、予期せず終了したり、応答を停止したりする場合があります。元のユニットに触れることなくすべてが再起動をトリガーするわけではないように、チェックを適用できます。サービス名を追加して、以下のコマンドを実行します。

sudo systemctl edit 

次に、以下を追加します。

[Service]
Restart=on-failure
RestartSec=5

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

StartLimitIntervalSec の組み合わせ と スタートリミットバースト これにより、壊れたサービスが無期限に再起動されなくなります。これらはクラッシュ ループを停止するために不可欠ですが、systemd 内で実行されるサービスに対してのみ機能します。

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

ウォッチドッグも systemd サービス管理も、それ自体では完了しません。ただし、組み合わせて使用すると、ほぼすべてのことに対応できます。

<先頭> <番目>

失敗の種類

<番目>

回復層

<番目>

期待される結果

サービスがエラーで終了します

systemd (失敗時再起動)

サービスは数秒以内に再起動します

サービスは正常に終了しますが、終了すべきではありません

systemd (再起動=常に)

サービスは数秒以内に再起動します

システム全体のフリーズまたは負荷スパイラル

ウォッチドッグ デーモン

自動再起動、手動ステップなし

systemd は、個々のサービスの障害を検出して再起動するのに適しており、ウォッチドッグはその上に位置してシステム全体を監視し、systemd の制限を超えて何か問題が発生した場合に再起動をトリガーします。

この組み合わせにより、何か問題が発生するたびに対応する必要がなくなり、サーバー管理がより快適になります。また、ほとんどのシステム問題の解決に役立つ特定の Linux コマンドを学習することも検討してください。