IBM / Lenovoサーバーでのウォッチドッグタイマー（デバイス/ dev /ウォッチドッグ）のサポートに関連するSLESの第12バージョンでの重大な後退に直面しました。
第一に、対象に誰かがいない場合の短い教育プログラム。 どのように機能し、なぜ必要なのですか？ 主題をすでに知っている人は、次の段落を安全にスキップできます。
サーバーおよび産業プラットフォームの一部として、特別なスキーム-ウォッチドッグがあります。 アクティブになると、プリセット時間（たとえば、1分）のカウントダウンが開始されます。 この時間中に彼に再度連絡しない場合、間隔の終わりにハードウェアのリロードが実行されます。 回すと、間隔が再びカウントされ始めます。 これは、オペレーティングシステムがフリーズした場合、または重要なソフトウェアサービスを提供した場合にコンピューターを自動的に復元するために必要です。 このようなソリューションは、高可用性（HA）クラスターおよび一定のシステム可用性を必要とするその他のアプリケーションでは必須です。 Intelアーキテクチャを搭載したコンピューターでは、システムメーカーに応じていくつかのハードウェアウォッチドッグタイマーインターフェイスが使用されますが、最も一般的なのはIntel TCO（iTCO）です。 Linuxでは、ウォッチドッグドライバーは、/ dev / watchdogデバイスの形式でプログラムインターフェイスを提供するカーネルモジュールとして実装されます。
現在Lenovoから入手可能なIBMのIntelサーバーでは、Intel TCOハードウェア層とそのサポートLinuxカーネルモジュールiTCO_wdtがウォッチドッグタイマーへのインターフェイスを担当しています。
現在（SLES12で）次のことが起こります。 iTCO_wdtモジュールがロードされ、システムログに診断が残されます：「iTCO_wdt：NO_REBOOTフラグをリセットできません。ハードウェア/ BIOSによりデバイスが無効になっています」は、メモリにロードされたままですが、何も実行せず、デバイス/ dev / watchdogは表示されません。 モジュールを手動でロードおよびアンロードしても、この動作は何も変わりません。 BIOSおよびIntegrated Service Module（IMM）設定もこれに影響しません。 この問題は、複数のIBM / Lenovo HS23およびx3250サーバーでまったく同じように現れます。
問題を解決するための回避策は、プログラムのカーネルレベルでエミュレートすることでウォッチドッグタイマーへのインターフェイスを提供する/etc/modules-load.dにソフトドッグモジュールを書き込むことです。 しかし実際には、これは単なるスタブであり、オペレーティングシステム自体の障害の問題を解決するものではありません。
さらに悪いことに、最近のSLES12の中間更新の1つでは、デフォルトでソフトドッグドライバがロードされていました。 この動作はすぐにオフになりましたが、Linuxの特定のバージョンを確認するまで、ハードウェアまたはソフトウェアドライバーがウォッチドッグサービスを提供するかどうかはわかりません。
問題を解決する方法があったようで、それについての新しい記事を書いて、一番上で言及しました。