LINUX.ORG.RU
решено ФорумAdmin

logrotate и copytruncate: почему размер файла не обнуляется?

 ,


0

1

Делаю такой тест:

Запускаю скрипт, который открывает файл в режиме чтения и дописывает в него по строке раз в 0.1 секунду.

Запускаю logrotate с опцией copytruncate в конфиге, который должен обрезать файл по достижении им maxsize 10K (и сжимать потом ротированное)

Что имею в итоге: сжатая копия файла лога создаётся, всё ОК.

Исходный файл при этом не обнуляется. При этом в режиме logrotate -v пишет, что он собирается обнулить файл, чего в действительности не происходит.

Судя по описанию copytruncate, он нужен как раз для моего целевого случая - а это сотни скриптов, написанных без малейшего представления о сигналах и каких-то там ротациях логов, пишущих в файлы до тех пор, пока файловая система не лопнет.

В общем, как же так и почему copytruncate столь странно себя ведёт? logrotate стоит версии 3.16 (проверял и на дистрибутивном 3.8).

P.S. Ведержка из man logrotate.conf, чтобы вам самим не искать:

copytruncate
Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one.
It can  be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. 
Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost.
★★★★★

Последнее исправление: DRVTiny (всего исправлений: 2)

Исходный файл при этом не обнуляется.

Не знаю, что происходит у вас, но файл именно должен выглядеть как забитый нулями с прежним размером. Truncate файла, в кторый ведётся запись приводит (на нормальных ФС) к образованию sparse (разряженного) файла. Физически на диске блоки под нули не занимаются.

Нужно различать скрипты, кторые пишут в лог каждый раз открывая его для дозаписи и скрипты, которые не делют close()/open(). Первым не нужны сигналы и пр. А со вторыми именно такие проблемы. Дескриптор файла в ядре содержит смещение от начала файла, по которому будет происходить следующая операция. И на него не повлиять извне, только сама программа может решить куда писать данные.

mky ★★★★★
()
Ответ на: комментарий от mky

Спасибо! Да, проблема именно в этом была: если открыть файл с флагом O_APPEND - всё становится на свои места и copytruncate работает правильно.

DRVTiny ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.