問題タブ [watchdog]

Windows サービスとして実装されている「ウォッチドッグ」と通信する C# (XP 組み込みで実行されている 2.0) のアプリケーションがあります。デバイスが起動すると、通常、このサービスが開始されるまでに時間がかかります。サービスが実行されているかどうか、コードから確認したいと思います。どうすればこれを達成できますか?

私は常に segfaults を行うスクリプトを持っています - segfault が python libxml バインディングにあるので解決できない問題 - それらを書きませんでした。わかりましたので、Linux では inf.loop を実行していたので、スクリプトが終了すると次のように再起動します。

まあ、FreeBSD では /bin/bash が見つからないようなので、うまくいきません。

何か案は？cron はオプションではないことを考慮してください。許可されるダウンタイムは数秒です。

Linux 用のシステム モニターを作成しており、いくつかのウォッチドッグ機能を含めたいと考えています。カーネルでは、/dev/watchdog が閉じられていてもウォッチドッグを継続するように構成できます。つまり、デーモンが正常に終了して /dev/watchdog を閉じた場合でも、システムは 59 秒後に再起動します。これは、ユーザーにとって望ましい動作である場合とそうでない場合があります。

SIGINT の処理方法に影響するため、デーモンにこの設定を認識させる必要があります。設定がオンの場合、デーモンは（できれば）終了時に整然としたシャットダウンを開始するか、（少なくとも）システムがまもなく再起動することをユーザーに警告する必要があります。

ユーザー空間からこの設定を取得する方法を知っている人はいますか? 値を取得するための sysconf() には何も表示されません。同様に、最初からソフトウェア ウォッチドッグが有効になっているかどうかを確認できる必要があります。

編集：

Linux は非常に単純なウォッチドッグ インターフェイスを提供します。プロセスは /dev/watchdog を開くことができます。デバイスが開かれると、そのファイルにデータが書き込まれない限り、カーネルは 60 秒のカウントダウンを開始して再起動します。そのファイルにデータが書き込まれると、クロックがリセットされます。

カーネルの構成方法によっては、そのファイルを閉じてもカウントダウンが停止する場合と停止しない場合があります。ドキュメントから：

カーネルが CONFIG_WATCHDOG_NOWAYOUT オプションを有効にしてコンパイルされていない限り、デバイス /dev/watchdog が正しく閉じられていれば、再起動せずにウォッチドッグを停止できます。

CONFIG_WATCHDOG_NOWAYOUT がユーザー空間デーモン内から設定されているかどうかを確認できる必要があるため、そのデーモンのシャットダウンを別の方法で処理できます。言い換えれば、その設定が高い場合、単純な:

... /dev/watchdog に何も書き込まれていないため、59 秒でシステムを再起動します。したがって、値が高く設定されている場合、SIGINT のハンドラーは追加の処理を行う必要があります (つまり、少なくともユーザーに警告します)。

ユーザー空間からこの設定を取得する方法が見つかりません:(どんな助けも大歓迎です。

マイクロコントローラにウォッチドッグがあり、キックされていない場合はプロセッサをリセットします。私のアプリケーションはしばらくの間正常に動作しますが、ウォッチドッグがキックされなかったため、最終的にリセットされます。プログラムをステップ実行すると、正常に動作します。

これをデバッグするにはどのような方法がありますか?

編集: 結論: バグを見つけた方法は、ウォッチドッグのパンくずリストでした。

高低の ISR ベクトルを持つ PIC を使用しています。High ベクトルは LED マトリックスを処理し、Low ベクトルはタイマー ティックを処理することになっていました。しかし、両方の ISR ハンドラーを高いベクトルに配置しました。そのため、LED マトリックス ISR を無効にし、タイマー ティック ISR にサービスが必要な場合、プロセッサはタイマー ティックを処理するために低い ISR でスタックしますが、タイマー ティック ハンドラーはそこにありませんでした。

ブレッドクラムは、私の検索を led マトリックスを処理し、具体的には LED マトリックス割り込みを無効にする関数に限定しました。

私は、サードパーティによって部分的に作成された、信頼性の低い（Qt / windows）アプリケーションを使用しています（責任を転嫁しようとしているだけです）。最新バージョンはより安定しています。ある種。クラッシュの報告は少なくなっていますが、ぶら下がっていて二度と戻ってこないという報告がたくさんあります。状況はさまざまで、収集できる情報が少ないため、問題を再現することはできませんでした。

理想的には、アプリケーションがロックされたことを認識し、クラッシュレポートを返送することを提案する、ある種のウォッチドッグを作成したいと思います。いいアイデアですが、問題があります。

• ウォッチドッグは、プロセスがハングしたことをどのように認識しますか？おそらく、ウォッチドッグに対して定期的に「すべて大丈夫」と言うようにアプリケーションをインストルメントしますが、十分な頻度で発生することが保証されているように、どこに配置すればよいのでしょうか。ロックされています。

• クラッシュが発生した場合、ウォッチドッグはどのような情報を報告する必要がありますか？WindowsにはまともなデバッグAPIがあるので、すべての興味深いデータにアクセスできると確信していますが、問題を追跡するのに何が役立つかはわかりません。

複数 (>20) のタスクが異なる優先度で実行されている組み込みシステムがあります。また、他のすべてのタスクがスタックしていないことを確認するために実行されるウォッチドッグ タスクもあります。ブルームーンに一度、タスクがチェックインされなかったためにシステムが再起動されるため、私のウォッチドッグは機能しています。

終了したタスクを特定するにはどうすればよいですか?

最も古いタスクがウォッチドッグをキックしたと非難することはできません。優先度の高いタスクが譲歩していないために延期された可能性があるからです。

助言がありますか？

現在、シングルスレッドアプリケーションで他の誰かのライブラリから関数 Foo を実行しています。ほとんどの場合、私は Foo を呼び出しますが、それは非常に迅速です。時には、Foo を呼び出すと、永遠に時間がかかります。私は忍耐強い人ではありません.Fooが永遠にかかる場合は、Fooの実行を停止し、それらの引数で呼び出したくありません.

特定の秒数後に実行を停止できるように、制御された方法 (現在の環境は POSIX/C++) で Foo を呼び出す最良の方法は何ですか。ここで行うべき正しいことは、Foo を呼び出す 2 番目のスレッドを作成することだと思いますが、メイン スレッドでは、時間切れになった場合に最終的に 2 番目のスレッドに通知するタイマー関数を作成します。

別のより適切なモデル (およびソリューション) はありますか? そうでない場合、Boost の Signals2 ライブラリと Threads でうまくいくでしょうか?

Windows サービスのウォッチドッグ タイマーに関する別の質問への回答に非常に興味があります (こちらを参照)。その答えは次のように述べています。

別のスレッドで実行されている内部ウォッチドッグ システムも使用しました。そのスレッドは、ログ出力やトグル イベントなどのアクティビティについてメイン スレッドを調べます。アクティビティが見られない場合、サービスはハングしていると見なされ、サービスをシャットダウンします。

この場合、停止したサービスを自動再起動するように Windows を構成すると、問題が解決する可能性があります (内部ロジックのバグでない限り)。

また、私が使用しているサービスには、ログに書き込まれるテキスト ログがあります。さらに、「少しだけスリープ」しようとしているサービスについては、次のウェイクアップの時間を記録します。MTAIL を使用してログの出力を監視しています。」

別のスレッドで実行されている内部ウォッチドッグを使用する方法のサンプルコードを誰か教えてください.

本当にありがとうございました。

私は：

• 無効化されたcron
• データベース ロギングの無効化
• キャッシュをクリアしました
• エラーとして表示されているコードをコメントアウト

それでも、同じエラー メッセージが Watchdog に書き込まれています。「ウォッチドッグから削除」を実行し、ウォッチドッグテーブルをチェックインした直後に同じエラーが発生します。

それが役立つというわけではありませんが、ここにエラーがあります：

と

だから、私の質問は次のとおりです。

1. この特定のエラーが何度もトリガーされている理由を確認する方法はありますか?
2. このエラーを「キャッシュ」しているのは何ですか?
3. これを引き起こしている可能性のある他のアイデアはありますか?

マルチスレッドプログラム（学生の宿題-バグの可能性が高い）をテストするためのコードを書いていますが、デッドロックを検出できるようにしたいと考えています。正しく実行されると、プログラムは定期的にstdoutへの出力を生成するため、かなり簡単になります。X秒間出力がない場合は、それを強制終了してデッドロックを報告します。関数プロトタイプは次のとおりです。

自分で書くこともできますが、正しく理解するのは少し難しいので、可能であれば既存のコードを使用したいと思います。誰かが似たようなものを書いた？

わかりました。以下の解決策をご覧ください。同様のことをしている場合は、サブプロセスモジュールも関連している可能性があります。