abrtがクラッシュしていないプロセスのログ出力を引き継ぐのはなぜですか？

簡潔なバージョン：

1. syslogに（詳細に）記録する長期実行プロセス（Webプロキシ）があります。
2. 何悪いことが起こったら突然介入何とか
3. プロセスは引き続き実行されます...
4. ...しかし、syslogに関するすべてのログメッセージは、「xfcproxy [1234]：」の代わりに「abrt：」と表示されます。
5. 理由をご存知ですか？

長いバージョン：

これは、ログの観点から見ることができる「何かが起こる」の例です。プロセスは記録され続けますが、syslog のプロセス名は変更されます。プロキシのすべてのメッセージが「uuid = ...」で始まる方法に注意してください。スニペットの上部にある「xfcproxy [4808]：」と、スニペットの下部にある「abrt：」の下に記録されたメッセージを表示できます。

Aug 27 07:02:55 proxy1 xfcproxy[4808]: uuid=63e63d9e connection=Open client_ip=192.168.3.21 client_port=40973
Aug 27 07:02:55 proxy1 xfcproxy[4808]: uuid=63e63d9e connection=Information method=CONNECT path=www.example.com port=443
Aug 27 07:02:55 proxy1 xfcproxy[4808]: uuid=63e63d9e rule=Destination message="Match made" rule=monitoring uri=www.example.com
Aug 27 07:02:55 proxy1 rsyslogd-2177: imuxsock begins to drop messages from pid 4808 due to rate-limiting
Aug 27 07:02:55 proxy1 abrtd: New client connected
Aug 27 07:02:55 proxy1 abrtd: Directory 'pyhook-2014-08-27-07:02:55-4808' creation detected
Aug 27 07:02:55 proxy1 abrt-server[27032]: Saved Python crash dump of pid 4808 to /var/spool/abrt/pyhook-2014-08-27-07:02:55-4808
Aug 27 07:02:55 proxy1 abrtd: Executable '/var/lib/xfcProxy/bin/xfcProxy.py' doesn't belong to any package and ProcessUnpackaged is set to 'no'
Aug 27 07:02:55 proxy1 abrtd: 'post-create' on '/var/spool/abrt/pyhook-2014-08-27-07:02:55-4808' exited with 1
Aug 27 07:02:55 proxy1 abrtd: Deleting problem directory '/var/spool/abrt/pyhook-2014-08-27-07:02:55-4808'
Aug 27 07:03:37 proxy1 rsyslogd-2177: imuxsock lost 1642 messages from pid 4808 due to rate-limiting
Aug 27 07:03:37 proxy1 abrt: uuid=06bc7247 connection=Open client_ip=192.168.3.21 client_port=40976
Aug 27 07:03:37 proxy1 abrt: uuid=06bc7247 connection=Information method=CONNECT path=www.example.com port=443
Aug 27 07:03:37 proxy1 abrt: uuid=06bc7247 rule=Destination message="Match made" rule=monitoring uri=www.example.com

「ps」を使用すると、実行中のPID 4808がまだ実行中であることを確認できます。

[root@proxy1 log]# ps 4808
  PID TTY      STAT   TIME COMMAND
 4808 ?        S      1:34 python /var/lib/xfcProxy/bin/xfcProxy.py
[root@proxy1 log]#

「imuxsockがメッセージの削除を開始しました」はやや正常です。このデーモンは非常に厄介です（ここでは連続メッセージの小さなサブセットのみを表示します）。レート制限の問題を除いて、一連のメッセージがレート制限を完全にトリガーする可能性があります。

abrtに関する私の知識は限られていますが、競合情報がないようですが、プロセスの競合はログタイミングに関連していると思います。

[root@proxy1 abrt]# pwd
/var/spool/abrt
[root@proxy1 abrt]# ls -l
total 4
-rw-r--r--. 1 root root  0 Mar 18 15:45 abrt-db
-rw-------  1 root root 33 Aug 27 07:02 last-via-server
[root@proxy1 abrt]# echo `cat last-via-server `
/var/lib/xfcProxy/bin/xfcProxy.py
[root@proxy1 abrt]#

問題のプロセスはマルチスレッドPythonプロセスです。スレッドを正しく整理しないため、この動作が発生するという考えにはっきりと開いています。これは本当に奇妙な行動です。

@Mikelの説明：

• はい、RHEL 6です。
• rsyslogによる/var/log/messages。まだジャーナリングを試みておらず、これらの変更を試みるには、非本番サーバーで再現する必要があります。

以下の賞金期間が更新されました。

申し訳ありませんが、次の理由でE Carter Youngの既存の回答に賞金を授与することはできません。

1. rsyslogソースを見てわかる限り、imuxsockレート制限はプロセスに対するいかなる種類の変更も引き起こさず、いかなる方法でもabrtdを含みません。一時的にストリームを停止し、後で読み取りを再開します。
2. プロセスがsyslogに過度に書き込むことは、バッファオーバーフローの状況ではありません。リソースの活用、はい。サービス拒否かもしれませんが、バッファと言ってもいっぱいになってもバッファオーバーフローが発生するわけではありません。
3. 説明されている手順は実際の状況と一致しません。特に、ステップ6でrsyslogはabrtプロセスから取得されませんが、元のプロセスでabrtという名前を使用するのはなぜですか？
4. 私はここにも競争条件があると信じていません。 （ログバッファをすばやく埋めることは競争条件ではありません）

この質問は複雑すぎてデータが足りないと思います。結局、より多くのデータを使用して質問できるいくつかの簡単な質問に帰結します。

• 定義によってabrtdがクラッシュしたプロセスで実行されている場合、終了しないプロセスで実行されるのはなぜですか？ abrtdが関連するのに十分な衝突を示すものは何ですか？私は消えたログに答えがあると思いますが、消えたログ自体が答えではないと思います。 rsyslog が abrtd を呼び出すという証拠はありません。
• rsyslogがプロセスでabrtdをトリガーした後にabrtをプロセス名として使用し始めるのはなぜですか？

残念ながら、今日は、より多くのデータを必要とせずにこれらの質問を提起するのは消極的です。

この答えを受け入れることはできませんが、確かに価値のある答えだと思います。

• abrtdブラックリストの説明
• 私が選択できるオプションを明確かつ簡潔に議論してください。
  • 速度制限とクラッタログの追加または削除
  • プロセス長の変更
  • abrtを使用してプロセスをブラックリストに追加して、プロセスが介入しないようにします。

したがって、賞金が期限切れになると、賞金の半分がE Carter Youngの回答に最も投票された回答に転送されます。