rsyslogd v3.xxは、名前付きパイプターゲットへの書き込み接続を予期せず閉じました。

rsyslogd v3.xxは、名前付きパイプターゲットへの書き込み接続を予期せず閉じました。

特定のログメッセージを名前付きパイプに転送するようにrsyslogを設定しました/tmp/logger.pipe。その後、名前付きパイプからデータを読み取る別のプロセスがあります。関連部品は以下で提供されます。/etc/rsyslog.conf

# Remote Logging (silly conditional rule needed for specific logging scenario)
$template RFC5424Format,"<%PRI%>1 %timegenerated:1:10:date-rfc3339%T%timegenerated:12:19:date-rfc3339%.%timegenerated:21:26:date-rfc3339%Z %HOSTNAME% - - -%msg%\n"
if ($msg contains 'remote="true"') then /tmp/logger.pipe;RFC5424Format

/tmp/logger.pipeの権限

prwxrwxrwx 1 ftp root 

このアプリケーションを2つの異なるコンピュータにデプロイしています。あるシステムには rsyslog v3.xx が装備され、もう一方のシステムには v5.xx が装備されています。

ここに画像の説明を入力してください。

ここに画像の説明を入力してください。

rsyslog v5.xx を使用するコンピュータではアプリケーションが正常に実行されますが、rsyslog v3.xx を使用するコンピュータでは奇妙な動作が発生します。具体的には次のようになります。

  1. rsyslogdは、初期起動時に起動に時間がかかることがあります(新しいルールを追加する前は非常に高速でした)。
  2. プロセスの読み取りがlogger.pipe再開されると、rsyslogdはリスニングプロセスが再開された後に名前付きパイプへのデータの書き込みを停止するようです。この問題を解決する唯一の方法は、rsyslogdを手動で再起動することです。

名前付きパイプを使用するときにrsyslog設定に欠けているいくつかのトリックがありますか?私が見落とす可能性がある他の権限の問題はありますか? v5.xx rsyslog バージョンでは非常に安定して実行されるため、アプリケーションに自信があります。残念ながら、問題のあるコンピュータではv3.xxのバージョンを更新できません。

どんなアイデアがありますか?

更新:問題を診断した可能性があります。リーダーがない場合、rsyslogdがパイプへの書き込み接続を閉じる問題のようです。ただし、リーダーアプリケーションはそのライターが表示されるまでブロックするfopen()を使用します。

何らかの理由で、これはrsyslog v5.xxでは問題になりません。

  1. rsyslogd と logger.out がパイプの初期状態を正常にオープンしました。

ここに画像の説明を入力してください。

  1. _logger.outで再起動の問題、rsyslogdはまだパイプへの書き込みを開いています。

ここに画像の説明を入力してください。

  1. _logger.outが修復され、すべてが再びうまく機能します。

ただし、この動作はrsyslog v3.xxとは異なります。

  1. rsyslogd と logger.out がパイプの初期状態を正常にオープンしました。

ここに画像の説明を入力してください。

  1. _logger.outで問題を再起動します。rsyslogdが何らかの理由でパイプへの接続を閉じました。

ここに画像の説明を入力してください。

答え1

rsyslog 文書によると、ターゲットにはパイプ記号を含める必要があります。この修正で私の問題は解決しました。 rsyslogは、リーダーが閉じていても、名前付きパイプへの接続を開いたままにします。

これがrsyslog v3.xxでのみ問題になる理由を説明できません。

ここに画像の説明を入力してください。

関連情報