изменения файла отслеживания kqueue - вероятность потери событий при обработке предыдущих?

Question

Что я делаю

Я реализующий Kqueue на основе решение для отслеживания изменений в конкретный логфайл, что, когда встретился с KQ_NOTE_WRITE fflag питона/(FreeBSD), то изменение файла определенно и обрабатывается другой функцией в моем скрипте python.

Почему я это делаю

В конце концов, я беру последнюю запись лог-файлов и отправки его в другом месте, как часть системы учета quick'n'dirty.

То, что я думаю, что мне нужно знать

1) Как файл_журнал может видеть периоды высокой проходимости, я задавался вопрос, будет ли какая-либо «атомарность», то есть при переходе от последней записи в лог-файл , будем ли мы «пропустить» новую запись? Тот факт, что kqueue является «очередью», я предполагал, что нет, но история научила меня, что я обычно чувствую себя как плункер для таких предположений.

2) Гарантировано ли kqueue для каждого события или может проскальзывать несколько событий? Случай, который я представляю, - это файл журнала, производящий две отдельные записи почти одновременно.

Любая мудрость/совет приветствуются.

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 происходит, «файл был написан» уведомление будет просто один уведомление. Это зависит от вашего кода, чтобы выяснить, сколько написано. Например, вы можете использовать fstat() для проверки длины файла на шаге 1, а затем еще fstat() после шага 5. Если файл только когда-либо добавлен, разница в размерах между этими точками - это «новые данные», которые вам нужны около.

Обратите внимание, что если вы видите (скажем) 100 байт на шаге 1 и 500 после шага 5, скажем, в шаге 7:

7: you fstat the file 

, а затем получить еще один «файл был написан» уведомление, это возможно что на самом деле был «шаг 6», где произошла другая запись с файлом. Поэтому вы должны быть готовы к еще более позднему шагу, чтобы найти, что добавлено 0 байтов, хотя вы получили уведомление о добавлении байтов, потому что вы, возможно, уже прочитали их после добавления примечания к kqueue.

Если вы смотрите журналы типа syslog, обратите внимание, что они «перевернуты» с переименованным файлом (а иногда и сжатым и т. Д.) И созданным новым файлом, например «сообщения» становятся «сообщениями.0». bz2 "и создаются новые" сообщения ". Вы можете посмотреть каталог вместе с файлом и проверить новые файлы, чтобы поймать такие случаи.