Очистка файла .

[ford1813]

Возник вопрос следующего характера.
Написал парсер лога pure-ftpd .
Вопрос в следующем . Во избежании путаницы с логами.
переименовываю текущий лог pure-ftpd сервера.
и создаю новый pureftpd.log с правами 0777 .
Соответственно pure-ftpd прекращает в лог писать, из за потери дескриптора к файлу.

Вопрос , как корректно очистить дескриптор файла , а не создавать новый.

удалите 1 тему ( лаг.

[Rootlexx]

wertik
Для этого в большинстве служб стоит обработка SIGHUP как сигнала переоткрытия файлов настройки и журнала.
Если быть точным, служба не теряет дескриптор.
Вообще, существуют две категории inode: on-disk и in-core. on-disk хранится на диске. Когда приложение открывает файл, on-disk inode загружается в оперативную память и превращается в in-core inode. Последний содержит всю информацию, содержащуюся в on-disk inode, но не только: там присутствует ещё счётчик, отслеживающий, сколько приложений открыло этот файл, и ещё некоторая информация (обязательные блокировки, ...). Когда приложение работает с файлом, оно работает с in-core inode. Поэтому файл можно спокойно удалить, при этом потеряется on-disk inode, что никак не повлияет на работу приложений с файлом, если он уже ими открыт, ибо работа ведётся уже через in-core inode.
Поэтому служба бужет продолжать писать в файл как ни в чём не бывало, только жёстких ссылок на него в файловой системе уже не останется.
Некоторые файлы, кстати, не имеют on-disk inode, как, например, обычные потоковые сокеты и неименованные каналы.

Добавлено: in-core inode иногда называют «vnode», тогда on-disk inode можно называть просто «inode».

[ford1813]

В какую тогда мне сторону продолжать движения для более детального решения моего вопроса.
Для начала попробовать не создавать новый файл вместо старого?.
А отследить будет ли он сам создан верно?

[Rootlexx]

В какую тогда мне сторону продолжать движения для более детального решения моего вопроса.

Думаю, что посыл сигнала SIGHUP должен заставить службу заново открыть файл журнала.

[ford1813]

Теперь более детально.
Открываем ftp сессию. предварительно удалили файл pureftpd.log
Скачиваю с фтп файла 1 файл.
Логи обновились.
Файл pureftpd.log создался вновь.
Удаляем его теперь.
Так как фпт сессия не закрыта , скачиваем второй файл.
Вот тут то и не создаётся pureftpd.log
А если открыть новую сессию то pureftpd.log если он отсутствовал создаётся.

В какую тогда мне сторону продолжать движения для более детального решения моего вопроса.

Думаю, что посыл сигнала SIGHUP должен заставить службу заново открыть файл журнала.

Спасибо почитаю.

В какую тогда мне сторону продолжать движения для более детального решения моего вопроса.

Думаю, что посыл сигнала SIGHUP должен заставить службу заново открыть файл журнала.

Спасибо почитаю.

[Rootlexx]

Вот тут то и не создаётся pureftpd.log
А если открыть новую сессию то pureftpd.log если он отсутствовал создаётся.

Ну конечно. Файл, видимо, остаётся открытым, поэтому не происходит его создание заново. Ведь когда происходит создание файла? — при открытии.
Если приложение не поддерживает методику SIGHUP, то тогда его никак не заставить заново создать файл.
А зачем вы вообще удаляете файл? Если хотите отдельно разбирать журналы, то проще скопировать его, а оригинал очистить, не удаляя.
На чём вы написали свой парсер?
Если C, то есть функции truncate() и ftruncate().

[ford1813]

Вот тут то и не создаётся pureftpd.log
А если открыть новую сессию то pureftpd.log если он отсутствовал создаётся.

Ну конечно. Файл, видимо, остаётся открытым, поэтому не происходит его создание заново. Ведь когда происходит создание файла? — при открытии.
Если приложение не поддерживает методику SIGHUP, то тогда его никак не заставить заново создать файл.
А зачем вы вообще удаляете файл? Если хотите отдельно разбирать журналы, то проще скопировать его, а оригинал очистить, не удаляя.

Парсер на perl.
Благодарю, посмотрю. Там насколько я помню у перла что то было по очистке файла.
Спасибо. Сплю. (

[watashiwa_daredeska]

А зачем вы вообще удаляете файл? Если хотите отдельно разбирать журналы, то проще скопировать его, а оригинал очистить, не удаляя.

Это в корне неправильно. Не делайте так никогда.

[nesk]

Возник вопрос следующего характера.
Написал парсер лога pure-ftpd .
Вопрос в следующем . Во избежании путаницы с логами.
переименовываю текущий лог pure-ftpd сервера.
и создаю новый pureftpd.log с правами 0777 .
Соответственно pure-ftpd прекращает в лог писать, из за потери дескриптора к файлу.

Вопрос , как корректно очистить дескриптор файла , а не создавать новый.

Мне кажется он не теряет дескриптор, а продолжает писать в старый файл! После открытия файла, процессу все равно как открытый файл будет называться в дальнейшем и будет ли у него имя вообще. Вы совсем неправильно работаете с логами.
надо как то так:
cp pureftpd.log <новое_имя>
>pureftpd.log

И будет Вам счастье.

[Rootlexx]

Это в корне неправильно. Не делайте так никогда.

Я внимательно слушаю, ожидая ваших предложений.

[nesk]

А зачем вы вообще удаляете файл? Если хотите отдельно разбирать журналы, то проще скопировать его, а оригинал очистить, не удаляя.

Это в корне неправильно. Не делайте так никогда.

Почему? Как раз так и надо делать.

[ford1813]

Ну я проще решил проблему.
выдержка из скрипта на perl.

#после экпорта открываем файл
open(F, '> /var/log/pureftpd.log');
#Чистим
print F "";
#Закрываем.
close(F);

Возник вопрос следующего характера.
Написал парсер лога pure-ftpd .
Вопрос в следующем . Во избежании путаницы с логами.
переименовываю текущий лог pure-ftpd сервера.
и создаю новый pureftpd.log с правами 0777 .
Соответственно pure-ftpd прекращает в лог писать, из за потери дескриптора к файлу.

Вопрос , как корректно очистить дескриптор файла , а не создавать новый.

Мне кажется он не теряет дескриптор, а продолжает писать в старый файл! После открытия файла, процессу все равно как открытый файл будет называться в дальнейшем и будет ли у него имя вообще. Вы совсем неправильно работаете с логами.
надо как то так:
cp pureftpd.log <новое_имя>
>pureftpd.log

И будет Вам счастье.

Угу и в мускуле будет куча одинаковых записей.
Замечательное предложение , спасибо. !!!
Не вариант.

[nesk]

Угу и в мускуле будет куча одинаковых записей.

Где? какие записи? Почему? Поясните.

По сути вы делаете это:
mv pureftpd.log <новое_имя>
>pureftpd.log

Да?
Если да, то правильней

cp pureftpd.log <новое_имя>
>pureftpd.log

Я наверно чего то не понимаю. Тогда извините

[ford1813]

Угу и в мускуле будет куча одинаковых записей.

Где? какие записи? Почему? Поясните.

По сути вы делаете это:
mv pureftpd.log <новое_имя>
>pureftpd.log

Да?
Если да, то правильней

cp pureftpd.log <новое_имя>
>pureftpd.log

Я наверно чего то не понимаю. Тогда извините

если постоянно копировать cp pureftpd.log <новое_имя>
и парсить скриптом файл <новое_имя> .
то у нас получится куча одинаковых данных.
в мускуле.
В общем не суть . Проблему решил. Скрипт который на перле парсит файл лога. После парсинга его чистит.
Что бы при новом по крону задании не делать
cp pureftpd.log <новое_имя>
парсим <новое_имя>.

А то получается данные по кругу будут вновь и вновь вливаться.

[nesk]

если постоянно копировать cp pureftpd.log <новое_имя>
и парсить скриптом файл <новое_имя> .
то у нас получится куча одинаковых данных.
в мускуле.

вызов creat к существующему файлу - приводит к очистки этого файла.
Это команда:
>pureftpd.log
если файл существует - очистит его.

[ford1813]

если постоянно копировать cp pureftpd.log <новое_имя>
и парсить скриптом файл <новое_имя> .
то у нас получится куча одинаковых данных.
в мускуле.

вызов creat к существующему файлу - приводит к очистки этого файла.
Это команда:
>pureftpd.log
если файл существует - очистит его.

А подробней можно про creat ?
Хотя я думаю что всё равно лучше реализовывать через скрипт.
Так как в случае ошибки при парсинге он не будет очищен.

[nesk]

А подробней можно про creat ?
Хотя я думаю что всё равно лучше реализовывать через скрипт.
Так как в случае ошибки при парсинге он не будет очищен.

Про creat подробней?
с точке зрения системный вызовов ядра creat это тоже самое, что open с флагами O_CREAT | O_WRONLY | O_TRUNC
если файла нет - создать и открыть на запись
если файл есть - опустошить и открыть на запись.
команда shell
>filename
приводит к тому, что shell сделает creat для filename
Файл удален не будет, но будет опустошен. Именно так надо делать ротацию журналов.

[Rootlexx]

wertik
nesk правильно всё написал, только на BASH.

Код: Выделить всё

cp pureftpd.log <новое_имя>         # эта команда, как вы и поняли, копирует файл журнала
> pureftpd.log                      # эта команда очищает оригинальный файл журнала, как я и предлагал ранее

По сути, то, что предложил nesk, — точно то же, что предложил я, так что всё нормально.

nesk
На пару секунд опередил .

[watashiwa_daredeska]

Я внимательно слушаю, ожидая ваших предложений.

Да ведь вы сами практически озвучили правильный и общепринятый способ:

Код: Выделить всё

mv log log.0
kill -HUP $pid
sleep $graceful_period

В этом сценарии возможны некоторые вариации. Например, kill -HUP может быть заменен на более специфическую программу. Как пример: http://httpd.apache.org/docs/2.2/logs.html#rotation

[ford1813]

Благодарствую.
Теперь всё понятно.
Даже более чем.
про > проглядел. меж строк читаю(
Спасибо всем.

[Rootlexx]

Я внимательно слушаю, ожидая ваших предложений.

Да ведь вы сами практически озвучили правильный и общепринятый способ:

Код: Выделить всё

mv log log.0
kill -HUP $pid
sleep $graceful_period

В этом сценарии возможны некоторые вариации. Например, kill -HUP может быть заменен на более специфическую программу. Как пример: http://httpd.apache.org/docs/2.2/logs.html#rotation

Вы невнимательно читаете. Я написал про этот вариант сразу же. Копирование и очистку предложил в случае, если программа, ведущая журнал, эту методику не поддерживает.

[watashiwa_daredeska]

Вы невнимательно читаете. Я написал про этот вариант сразу же. Копирование и очистку предложил в случае, если программа, ведущая журнал, эту методику не поддерживает.

Вы невнимательно пишете Рецепт mv && kill -HUP в явном виде вы не озвучили, хотя привели пространные объяснения, а рецепт cp && >log был предложен:

А зачем вы вообще удаляете файл? Если хотите отдельно разбирать журналы, то проще скопировать его, а оригинал очистить, не удаляя.

Лично я, каюсь, не понял, что это только для случая, когда программа не поддерживает SIGHUP.
Проблема же в том, что если программа не поддерживает SIGHUP, то ей уже ничего не поможет. Если делать cp log log.0 && :>log, то:

• Возникает состязание и некоторые записи могут быть потеряны
• Начало лога размером с записанный до truncate будет забито символами с кодом 0 (хотя эти символы и не будут занимать место на диске).

[Rootlexx]

Рецепт mv && kill -HUP в явном виде вы не озвучили

А зачем озвучивать в явном виде рецепт на BASH, если не ясно, на каком языке автор написал свой парсер? Разве недостаточно:

Для этого в большинстве служб стоит обработка SIGHUP как сигнала переоткрытия файлов настройки и журнала.

Думаю, что посыл сигнала SIGHUP должен заставить службу заново открыть файл журнала.

?

рецепт cp && >log был предложен

Заметьте, не мной.

Проблема же в том, что если программа не поддерживает SIGHUP, то ей уже ничего не поможет. Если делать cp log log.0 && :>log, то:
Возникает состязание и некоторые записи могут быть потеряны

Осмелюсь указать вам, что при простом удалении файла с последующим посылом сигнала тоже могут быть проблемы. SIGHUP вообще не является сигналом реального времени, никто не гарантирует, когда он дойдёт, когда будет обработан, мало того, при множественном посыле этого сигнала и достаточно медленной его обработке часть сигналов просто потеряется (вообще, все кроме первых двух, включая обрабатываемый в данный момент).

Лично я, каюсь, не понял, что это только для случая, когда программа не поддерживает SIGHUP.

Наверное, потому, что в явном виде я этого не озвучил. Однако, та фраза, которую вы процитировали, была мной озвучена аж в третьем сообщении, причём прямо перед этим я написал:

Если приложение не поддерживает методику SIGHUP, то тогда его никак не заставить заново создать файл.

Думаю, очевидно, почему я предложил этот вариант.
Вообще, узкое место в копировании файла журнала с его последующим удалением заключается в отсутствии уведомления пишущей программы об изменении файла.
Подытоживая, моя точка зрения следующая:
1. Если приложение поддерживает соответствующую обработку SIGHUP, использовать этот механизм.
2. Если 1. не выполняется, использовать копирование и очистку за неимением других вариантов.
Если есть желание продолжать обсуждение, предлагаю переместиться в личку, ибо здесь уже пошло отхождение от темы.

[Portnov]

Обычно для очистки лога используют всё-таки
>file.log
(или echo -n > file.log). При этом файл не удаляется, его дескрипторы не меняются, но содержимое исчезает.

[ford1813]

Ну виноват я только не сорьтесь.
bash скрипт я уже не использую. в крон перл засунул.