Почему только некоторые мои журналы меняют?

Задача Logrotate - перемещать (переименовывать) и сжимать файлы. Вы сконфигурировали его в этом случае, чтобы переименовать и сжать файлы журнала Rails, а затем создать новые с исходными именами.

Имена файлов - это способ поиска файла, но фактический файл - это просто некоторые пространство на диске. Файл может иметь несколько имен (жестких ссылок) или без имен (вы можете rm открыть файл, но он по-прежнему занимает место на диске, пока файл открыт в некотором процессе).

[d2 ] Проблема, с которой вам кажется, заключается в том, что приложение Rails уже открыло файл, когда оно переименовано. Регистратор Rails не замечает изменения имени, потому что он использует имя один раз, чтобы открыть файл, а затем полностью перестало заботиться о его имени.

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

Если вы посмотрите в /etc/logrotate.d, вы увидите много примеров этого, в зависимости от того, что вы установили.

[d5 ] Например, rsyslog имеет:

postrotate
    invoke-rc.d rsyslog rotate > /dev/null
endscript

stunnel имеет:

postrotate
    /etc/init.d/stunnel4 reopen-logs > /dev/null
endscript

Это скрипты, чтобы сообщить соответствующему процессу, что файл нуждается в повторном открытии. Конкретный механизм зависит от программы, но то, что это имеет тенденцию делать, - это отправить HUP (или иногда USR1) (см. [F9]), которые длительные процессы принимают как инструкцию для закрытия и повторного открытия logfiles.

В случае с Rails способ его изменения зависит от того, какой логгер вы используете. Я только что видел несколько советов, предполагающих, что вы должны использовать copytruncate, который в основном является «чит-вариантом» в logrotate, говорящим, что он вручную копирует содержимое и пуст файл, а не перемещает его и создает новый. (см. man logrotate.conf). Это используется вместо create следующим образом:

/home/rails/myapp/log/*.log {
    daily
    missingok
    compress
    notifempty
    rotate 12
    copytruncate
    delaycompress
    missingok
    su rails rails
}

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

Однако, если вы используете Unicorn для запуска вашего приложения (которое мультиплексирует запросы через кучу идентичных рабочих процессов Rails), он поддерживает сигнал USR1 как обычно (убивая и заменяя все рабочие, что фактически заставляет их повторно открывать файлы), и вы можете просто отправить его в postrotate с помощью pkill или аналогичного, возможно, так:

/home/rails/myapp/log/*.log {
    daily
    missingok
    compress
    notifempty
    rotate 12
    create
    delaycompress
    missingok
    su rails rails
    postrotate
        pkill -USR1 -u rails unicorn
    endscript
}

pkill - это инструмент для искать запущенные процессы и отправлять им сигналы, так что это найдет все с именем unicorn, запущенным как пользователь rails, и отправит ему сигнал USR1, который сообщает ему повторно открыть файлы журнала. (Примеры, которые я дал из файлов Ubuntu пакетов /etc/logrotate.d, фактически делают то же самое, но эти службы имеют поиск, скрытый в функциях в их сценариях /etc/init.d.)

Я уверен, что быть каким-то образом настроить разумную postrotate для любой настройки Rails, которую вы получили (в худшем и простом случае, просто перезапустите ее), но, надеюсь, это объясняет все стороны Ubuntu ...

Задача Logrotate - перемещать (переименовывать) и сжимать файлы. Вы сконфигурировали его в этом случае, чтобы переименовать и сжать файлы журнала Rails, а затем создать новые с исходными именами.

Имена файлов - это способ поиска файла, но фактический файл - это просто некоторые пространство на диске. Файл может иметь несколько имен (жестких ссылок) или без имен (вы можете rm открыть файл, но он по-прежнему занимает место на диске, пока файл открыт в некотором процессе).

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

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

Если вы посмотрите в /etc/logrotate.d, вы увидите много примеров этого, в зависимости от того, что вы установили.

Например, rsyslog имеет:

postrotate invoke-rc.d rsyslog rotate > /dev/null endscript

stunnel имеет:

postrotate /etc/init.d/stunnel4 reopen-logs > /dev/null endscript

Это скрипты, чтобы сообщить соответствующему процессу, что файл нуждается в повторном открытии. Конкретный механизм зависит от программы, но то, что это имеет тенденцию делать, - это отправить HUP (или иногда USR1) (см. [F9]), которые длительные процессы принимают как инструкцию для закрытия и повторного открытия logfiles.

В случае с Rails способ его изменения зависит от того, какой логгер вы используете. Я только что видел несколько советов, предполагающих, что вы должны использовать copytruncate, который в основном является «чит-вариантом» в logrotate, говорящим, что он вручную копирует содержимое и пуст файл, а не перемещает его и создает новый. (см. man logrotate.conf). Это используется вместо create следующим образом:

/home/rails/myapp/log/*.log { daily missingok compress notifempty rotate 12 copytruncate delaycompress missingok su rails rails }

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

Однако, если вы используете Unicorn для запуска вашего приложения (которое мультиплексирует запросы через кучу идентичных рабочих процессов Rails), он поддерживает сигнал USR1 как обычно (убивая и заменяя все рабочие, что фактически заставляет их повторно открывать файлы), и вы можете просто отправить его в postrotate с помощью pkill или аналогичного, возможно, так:

/home/rails/myapp/log/*.log { daily missingok compress notifempty rotate 12 create delaycompress missingok su rails rails postrotate pkill -USR1 -u rails unicorn endscript }

pkill - это инструмент для искать запущенные процессы и отправлять им сигналы, так что это найдет все с именем unicorn, запущенным как пользователь rails, и отправит ему сигнал USR1, который сообщает ему повторно открыть файлы журнала. (Примеры, которые я дал из файлов Ubuntu пакетов /etc/logrotate.d, фактически делают то же самое, но эти службы имеют поиск, скрытый в функциях в их сценариях /etc/init.d.)

Я уверен, что быть каким-то образом настроить разумную postrotate для любой настройки Rails, которую вы получили (в худшем и простом случае, просто перезапустите ее), но, надеюсь, это объясняет все стороны Ubuntu ...

Задача Logrotate - перемещать (переименовывать) и сжимать файлы. Вы сконфигурировали его в этом случае, чтобы переименовать и сжать файлы журнала Rails, а затем создать новые с исходными именами.

Имена файлов - это способ поиска файла, но фактический файл - это просто некоторые пространство на диске. Файл может иметь несколько имен (жестких ссылок) или без имен (вы можете rm открыть файл, но он по-прежнему занимает место на диске, пока файл открыт в некотором процессе).

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

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

Если вы посмотрите в /etc/logrotate.d, вы увидите много примеров этого, в зависимости от того, что вы установили.

Например, rsyslog имеет:

postrotate invoke-rc.d rsyslog rotate > /dev/null endscript

stunnel имеет:

postrotate /etc/init.d/stunnel4 reopen-logs > /dev/null endscript

Это скрипты, чтобы сообщить соответствующему процессу, что файл нуждается в повторном открытии. Конкретный механизм зависит от программы, но то, что это имеет тенденцию делать, - это отправить HUP (или иногда USR1) (см. [F9]), которые длительные процессы принимают как инструкцию для закрытия и повторного открытия logfiles.

В случае с Rails способ его изменения зависит от того, какой логгер вы используете. Я только что видел несколько советов, предполагающих, что вы должны использовать copytruncate, который в основном является «чит-вариантом» в logrotate, говорящим, что он вручную копирует содержимое и пуст файл, а не перемещает его и создает новый. (см. man logrotate.conf). Это используется вместо create следующим образом:

/home/rails/myapp/log/*.log { daily missingok compress notifempty rotate 12 copytruncate delaycompress missingok su rails rails }

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

Однако, если вы используете Unicorn для запуска вашего приложения (которое мультиплексирует запросы через кучу идентичных рабочих процессов Rails), он поддерживает сигнал USR1 как обычно (убивая и заменяя все рабочие, что фактически заставляет их повторно открывать файлы), и вы можете просто отправить его в postrotate с помощью pkill или аналогичного, возможно, так:

/home/rails/myapp/log/*.log { daily missingok compress notifempty rotate 12 create delaycompress missingok su rails rails postrotate pkill -USR1 -u rails unicorn endscript }

pkill - это инструмент для искать запущенные процессы и отправлять им сигналы, так что это найдет все с именем unicorn, запущенным как пользователь rails, и отправит ему сигнал USR1, который сообщает ему повторно открыть файлы журнала. (Примеры, которые я дал из файлов Ubuntu пакетов /etc/logrotate.d, фактически делают то же самое, но эти службы имеют поиск, скрытый в функциях в их сценариях /etc/init.d.)

Я уверен, что быть каким-то образом настроить разумную postrotate для любой настройки Rails, которую вы получили (в худшем и простом случае, просто перезапустите ее), но, надеюсь, это объясняет все стороны Ubuntu ...