Усечение файла, в то время как это используется (Linux)

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

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

kill -HUP [идентификатор-процесса]

А затем он снова начнет записывать.

В качестве альтернативы (как предложил Билли), возможно, перенаправить вывод из приложение к программе регистрации, такой как multilog, или той, которая обычно используется с Apache, известная как cronolog. Тогда у вас будет более точный контроль того, где все идет, до того, как оно будет записано в этот начальный файловый дескриптор (файл), а это действительно все.

В Linux (на самом деле все унициклы) файлы создаются, когда они открываются, и удаляются, когда на них ничего не ссылается. В этом случае программа, открывшая его, и каталог, в котором он был открыт, содержат ссылки на файл. Когда программа cp хочет записать в файл, она получает ссылку на него из каталога, записывает нулевую длину в метаданные, хранящиеся в каталоге (это небольшое упрощение), и отказывается от дескриптора. Затем исходная программа, по-прежнему удерживая исходный дескриптор файла, записывает в файл еще несколько данных и сохраняет ту длину, которая, по ее мнению, должна быть.

даже если вы удалите файл из каталога, программа продолжит записывать в него данные (и использовать дисковое пространство), даже если никакая другая программа не сможет ссылаться на него.

Короче говоря, если у программы есть ссылка (дескриптор) на файл, ничто из того, что вы делаете, не изменит этого.

Теоретически существуют способы изменения поведения программ путем установки LD_LIBRARY_PATH для включения программы, которая перехватывает все системные вызовы доступа к файлам. Я помню, что где-то видел что-то подобное, но не могу вспомнить название.

Попробуйте > файл .

Обновите комментарии: у меня он отлично работает:

robert@rm:~> echo "content" > test-file
robert@rm:~> cat test-file 
content
robert@rm:~> > test-file
robert@rm:~> cat test-file 

Интересная особенность этих восстановленных файлов заключается в том, что первые 128 КБ или около того будут содержать все нули после того, как вы усечете файл, скопировав поверх него / dev / null . Это происходит из-за того, что файл усечен до нулевой длины, но дескриптор файла в приложении по-прежнему указывает сразу после его последней записи. При повторной записи файловая система обрабатывает начало файла как все нулевые байты - без фактической записи нулей на диск.

В идеале, вам следует попросить поставщика приложения открыть файл журнала с Флаг O_APPEND . Это означает, что после усечения файла следующая запись будет неявно искать до конца файла (то есть вернуться к нулевому смещению), а затем запишет новую информацию.

во время использования файла, если вы попытаетесь обнулить его или что-то в этом роде, иногда это может «сбить с толку» приложение, которое записывает в файл журнала, и после этого оно может ничего не записывать.

Что я бы попробовал сделать, так это настроить своего рода прокси / фильтр для этого журнала, вместо перенаправления в файл, перенаправления на процесс или что-то еще, что будет получать ввод и записывать в текущий файл.

Возможно, это можно сделать с помощью сценария, иначе вы могли бы написать для этого простое приложение (java или что-то еще). Влияние на производительность приложения должно быть довольно небольшим, но вам придется провести несколько тестов.

Кстати, ваше приложение является автономным веб-приложением, ... ? Может быть, есть другие варианты, которые нужно изучить.

Изменить: есть также Оператор перенаправления добавления >> , который я лично никогда не использовал, но он может не блокировать файл.

Начиная с coreutils 7.0, появилась команда truncate.