web-dev-qa-db-ja.com

プロセスが強制終了されましたが、カーネル通知を理解できません

組み込みのx86セットアップ（buildrootとuClibcを使用して構築）で実行されているカスタムアプリケーションがあります。アプリケーションは正常に実行されていますが、今朝仕事に戻ったときに、プロセスが強制終了され、ターミナルに次の出力が表示されていることがわかりました。

SAK: killed process 1008 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1009 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1011 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1012 (CX_SC3): fd#4 opened to the tty

これで、CX_SC3が私のプロセスになりました。複数のスレッドがあり、そのうちの1つが/dev/ttyS0を開いて、無線モデム経由でメッセージを送信します。シリアルポートのfd番号は4です。私が理解していないのは

  1. SAKの意味
  2. 上記のPIDは、アプリケーションのインスタンスが一度に1つしか実行されていないため、アプリケーションによって強制終了されたプロセスを参照している必要があります。これらのPIDが実際に私のスレッドIDである可能性はありますか（私のアプリケーションは常に4つのスレッドを実行するため）。
  3. アプリケーションが他のプロセスを強制終了した場合、なぜアプリケーションも強制終了されたのですか？
  4. opened to the ttyの部分はどういう意味ですか？いくつかの調査から、これは、私がプログラムを開始するために使用したttyに送信された割り込み文字と関係があることを示唆しています。

次の出力につながる可能性のあるイベントは何ですか？私の組み込みセットアップは非常に小さく、busyboxを使用し、vsftpdを実行し、カスタムアプリケーション以外はほとんど実行しません。私のアプリケーションが堅牢であることが重要です。

EDIT：以下のコメントに応えて、これがSAKの検出によるものである場合、誤ってこれをトリガーする可能性のあるものはありますか？シリアルポートで読み取られているものがこれをトリガーした可能性はありますか？また、システムのSAKの組み合わせを見つけるにはどうすればよいですか？ルートファイルシステムのどこにもrc.sysinitまたはrc.localファイルがありません。

PDATE：このイベントを、ホストマシンがシャットダウンするポイントまで固定することができました。ホストマシンとターゲットデバイスの間にシリアルケーブルがあり、これを使用して組み込みターゲットにシリアルデータを送信しています。ターゲットを実行したままにしてホストをシャットダウンすると、上記のようにアプリケーションが強制終了されます。ホストマシンをシャットダウンする前にシリアルケーブルを外すと、アプリケーションが強制終了されず、通常どおり実行されます。この動作は、実行した後でも発生します

echo 0 > /proc/sys/kernel/sysrq

アドバイス通り。

linuxkernelttykillserial-port
6
mathematician1975

この場合のSAKは、実際には Secure Attention Key を意味します。表示されているメッセージは、 drivers/tty/tty_io.c で定義されているカーネルメッセージです。 SAKは、コンソール上のユーザーの安全なログインを保証するキーの組み合わせです。 Linuxでは、SAKは、SAKが呼び出されるターミナルに接続されているすべてのプロセスを強制終了することでこれを保証します。 initは、 getty の後にloginまたはXのように信頼できるログインプロセスを再開することが期待されます。 serverwithdisplay manager。

リストされているPIDは、実際には、SAKによって強制終了されたアプリケーションCX_SC3のスレッドのPIDです。

fd#n opened to the ttyは、強制終了されたプロセス/スレッドのファイル記述子nがSAKのある端末に対して開かれていることを意味します呼び出されました。

Linuxでは、2つの方法があります SAKを呼び出す ：

  1. magic SysRq キーを介して-通常 Alt+SysRq+K （仮想端末）または BreakK （シリアルコンソール）。あなたはすでに魔法を無効にしようとしたので、これはあなたのケースではありません SysRqecho 0 > /proc/sys/kernel/sysrqで送信します BreakK 偶然のシーケンスはありそうにありません。

  2. 定義されたキーシーケンス（仮想端末）またはブレーク信号（シリアルコンソール）を介して。シリアルコンソールでのSAKの可用性は、setserialによって制御されます。

ブレーク信号 シリアルラインでは、文字送信時間（開始、停止、パリティビットを含む）よりも長い時間にわたって間隔値が連続して送信されます。この場合、ホストマシンのシャットダウン中にBreak信号の状態が表示される可能性が高くなります。 setserial ：によって、ターゲットデバイスのシリアルポートでSAKをオフにしてみてください。

setserial /dev/ttyS0 ^sak

シリアルポートのSAK機能ステータスはsetserial -g /dev/ttyS0で確認できます。オンにすると、Flags:の後にSAKが表示されます。起動後のオプションの自動設定については、BusyBoxシステムでは通常/etc/init.d/rcSおよび/etc/rc.d/S*である起動スクリプトを参照するか、他の可能性について /etc/inittab を確認してください。

8
pabouk

私はpaboukの答えの助けを借りて問題を解決することができました。ユーザースペースAPIを使用して開くときにシリアルポートでSAKフラグを設定/設定解除できるようにする、私が最終的に発見したコードベースのソリューションは、stackoverflowで見つけることができます シリアルポートSAKを無効にするにはどうすればよいですか？ユーザースペースAPIを使用するLinuxのオプション？

4
mathematician1975