python - kqueue 跟踪文件更改 - 在处理以前的事件时有可能丢失事件吗？

Question

我在做什么

我正在实现一个基于 python/kqueue (FreeBSD) 的解决方案来跟踪对特定日志文件的更改，当满足 KQ_NOTE_WRITE fflag 时，对文件的更改将由我的 python 脚本中的另一个函数获取和处理.

我为什么要这样做

最终，我将获取最新的日志文件条目并将其发送到其他地方，作为 quick'n'dirty 会计系统的一部分。

我认为我需要知道的事情

1) 由于日志文件可以看到高流量时期，我想知道是否会有任何“原子性”，即在将最新条目传递到日志文件时，我们会“错过”一个新条目进来吗？ kqueue 是一个“队列”这一事实，我认为不是，但历史告诉我，对于这样的假设，我通常最终会感觉自己像个笨蛋。

2) kqueue 是否保证为每个事件触发，或者多个事件是否会漏掉？我想象的情况是日志文件几乎同时生成 2 个单独的条目。

感谢任何智慧/建议。

Answer 1

你的怀疑是正确的。 :-)

当第二个相同事件发生时，如果 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() 检查文件的长度，然后在第 5 步之后使用另一个 fstat()。如果文件只是曾经附加到，这些点之间的大小差异是您关心的“新数据”。

请注意，如果您在第 1 步看到(比如说)100 个字节，在第 5 步之后看到(比如说)500 个字节——比如说，在第 7 步:

7: you fstat the file

然后又收到另一个“文件已写入”通知，可能实际上有一个“第 6 步”，文件发生了另一次写入。因此，即使您收到添加了字节的通知，您也应该准备好在更晚的步骤中发现添加了 0 个字节，因为在将注释附加到 kqueue 之后您可能已经读取了它们。

如果您正在观看 syslog 类型的日志，请注意它们会“翻转”文件并重命名(然后有时压缩等)并创建一个新文件，例如“messages”变成“messages.0.bz2”并创建一个新的“messages”。您可以查看目录和文件，并检查是否有新文件创建，以捕获此类情况。