Оновіть не повторне відкриття файлів журналів під час логротації

Ми використовуємо upstart для управління нашими послугами на наших серверах Ubuntu. Вони створюють журнали, які вийшли в /var/log/upstart/SERVICE_NAME.log

Потім щодня файли журналу обертаються за допомогою сценарію логротації, який поставляється з 12.04 LTS:

/var/log/upstart/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        nocreate
}

Проблема полягає в тому, що в той час, коли logrotate переміщує файли, воно не здається сигналом для запуску для закриття та повторного відкриття файлів, залишаючи процес запуску запису на видалення PID.

init          1       root    8w      REG              202,1        64       2431 /var/log/upstart/dbus.log.1 (deleted)
init          1       root   13w      REG              202,1        95       2507 /var/log/upstart/acpid.log.1 (deleted)
init          1       root   14w      REG              202,1       127      17377 /var/log/upstart/whoopsie.log.1 (deleted)
init          1       root   36w      REG              202,1       122       6747 /var/log/upstart/SERVICE_NAME.log.1 (deleted)
init          1       root   37w      REG              202,1        30       6762 

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

Я вважаю, у вас є 3 варіанти.

1. Ви змінюєте існуючу конфігурацію, додаючи "copytruncate"

   /var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }

2. Якщо ви не можете або (заборонено) змінювати існуючий конфігурацію logrotate через інші файли журналу, які не страждають, а існуючий конфігурація працює для них, тоді перемістіть свої файли "SERVICE_NAME.log" у нову папку під / var / log, якщо бажаєте, створіть новий конфігурацію з "copytruncate" та додайте її до cron.daily.

3. а) Якщо вам заборонено змінювати конфігурацію хоста os logrotate або додати її до cron.daily ОС хоста, тоді ваш третій варіант - це зміни сценаріїв або програм, щоб перевірити, чи існує файл, перш ніж виписувати у файл. b) Інший спосіб - трохи вище пункту 2, який полягає в тому, щоб перемістити свої логіни кудись в іншому місці, а всередині вас сценарій або програма, виконати команду logrotate, специфічну для журналу файлів програми.

Точка 3b вище є більш хитрою, але більш елегантною, і це те, що я використовую більшу частину часу, оскільки це означає, що програма є самодостатньою і самокерованою і не потребує завдань ОС для няні.

Щоб дізнатися, як вручну запустити логротат і додати його до програми чи сценарію, просто введіть:

man logrotate

або

logrotate --help

Якщо ви використовуєте Python для своїх програм, ви можете перевірити, як ця програма використовує його для самостійного керування файлами журналу. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Виявляється, це відома проблема, і квиток залишається відкритим, коли я його набираю.

Найвірогідніше - це, мабуть, просто видалити /etc/logrotate.d/upstartцілком і повернути файли окремих служб окремо. Оскільки каталог ( /var/log/upstart/) містить лише stdout / stderr різних служб - і жодна служба, яка мала на меті працювати як демон, не повинна виводити ці два канали взагалі. За винятком, можливо, при самому запуску.

У системах управління я, три служби знаходяться в веденні вискочки: php5.6-fpm, php7.1-fpmі acpid. Жоден із трьох журналів не активний, але іноді fpm перезапускається через /var/log/php5.6-fpm.logобертання його основного файлу журналу ( ) - і це викликає цей шум, оскільки він видає деяку нерозумність при запуску.

Якщо ви все одно наполягаєте на повороті цих файлів, ви можете розраховувати на те, що їхні назви відповідають назвам служб та використовувати такий postrotateсценарій:

    postrotate
            service=${1##*/}
            service=${service%.log*}
            service $service restart > /dev/null
    endscript

Щоб вищезазначене спрацювало, не використовуйте там sharedscriptsдієслово - мій скрипт покладається на те, що фактичний шлях до файлу буде переданий йому як перший аргумент ( $1).

(Перенаправлення на /dev/nullкорисно, тому що service-команда шумно - і ви не хочете, щоб такий шум надсилався вам електронною поштою. Зауважте, що я не переспрямовую stderrтуди, лише stdoutякщо є проблема, ви Ви все одно отримаєте ваш електронний лист про це.)