3

私がしていること

KQ_NOTE_WRITE fflag が満たされると、ファイルへの変更が取得され、Python スクリプト内の別の関数によって処理されます。

なぜ私はそれをやっている

最終的に、私は最新のログファイル エントリを取得し、迅速で汚れた会計システムの一部として別の場所に送信します。

私が知る必要があると思うこと

1）ログファイルはトラフィックの多い期間を確認できるため、「原子性」があるかどうか、つまり、最新のエントリをログファイルに渡しているときに、入ってくる新しいエントリを「見逃す」のではないかと思いました。kqueue が「キュー」であるという事実は、私はそうではないと思っていましたが、歴史は、私が通常、そのような仮定のいたずら者のように感じることになることを教えてくれました。

2) イベントごとに kqueue が起動することが保証されているか、または複数のイベントがすり抜ける可能性がありますか? 私が想像しているケースは、ほぼ同時に 2 つの別々のエントリを生成するログファイルです。

知恵/アドバイスをいただければ幸いです。

4

1 に答える 1

4

あなたの疑いは正しいです。:-)

2 番目の同一イベントが発生したときに消費されていない場合、kqueue の「イベント」は「展開」されます。つまり、低レベルでの一連のイベントが次のようなものであるとします。

1: you start monitoring the log file for writes
2: something writes to the log file (this adds a "write" notice to the kqueue)
3: your process is notified, but does not have a chance to go look yet
4: something (same something as step 2, or different, does not matter)
   writes more to the log file (this merely "expands" the existing notice,
   with no effect in this case)
5: your process finally gets a chance to read the "file was written" notice
   from the kqueue

ステップ 5 が発生すると、「ファイルが書き込まれました」という通知だけが 1 つの通知になります。書き込まれた量を把握するのはコード次第です。たとえば、fstat()ステップ 1 でファイルの長さを確認し、fstat()ステップ 5 の後に別のファイルの長さを確認するために使用できます。ファイルが追加されるだけの場合、これらのポイント間のサイズの違いは、気にする「新しいデータ」です。

ステップ 1 で (たとえば) 100 バイトが表示され、ステップ 5 の後に 500 バイトが表示される場合 (たとえば、ステップ 7 で) に注意してください。

7: you fstat the file

その後、別の「ファイルが書き込まれました」という通知が表示された場合、実際には「ステップ 6」でファイルへの別の書き込みが発生した可能性があります。そのため、kqueue にメモが追加された後に既にそれらを読んでいる可能性があるため、バイトが追加されたという通知を受け取ったとしても、さらに後のステップで 0 バイトが追加されたことを確認する準備をする必要があります。

タイプ ログを監視している場合はsyslog、ファイルの名前が変更されて (場合によっては圧縮されるなどして) 「裏返され」、新しいファイルが作成されることに注意してください。たとえば、「メッセージ」は「メッセージ.0.bz2」になり、新しい「メッセージ」が作成されます。ファイルとともにディレクトリを監視し、新しいファイルの作成を確認して、そのようなケースをキャッチできます。

于 2013-03-08T10:37:51.137 に答える