Upstart не открывает файлы журналов на logrotation

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

Затем ежедневно файлы журналов чередуются с помощью сценария logrotation, который поставляется с 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. a) Если вам не разрешено изменять конфигурацию host os logrotate или добавлять в cron.daily операционной системы хоста, тогда ваш третий вариант - изменить сценарии или программы, чтобы либо проверить, существует ли файл перед записью в файл. б) Другой способ - чуть-чуть пункта 2 выше, который заключается в том, чтобы переместить ваши файлы журналов в другое место, а внутри вашего скрипта или программы выполнить команду logrotate, специфичную для файла журнала этой программы.

Пункт 3b выше более сложный, но более элегантный, и именно этим я и пользуюсь большую часть времени, поскольку это означает, что программа самодостаточна и управляется самостоятельно, и ей не нужны рабочие места ОС, чтобы присматривать за ней.

Чтобы узнать, как вручную запустить logrotate и добавить его в вашу программу или скрипт, просто наберите:

man logrotate

или

logrotate --help

Если вы используете Python для своих программ, вы можете проверить, как эта программа использует его для самостоятельного управления файлами журналов. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Оказывается, это известная проблема, и билет остается открытым, когда я набираю это.

Правильнее всего, наверное, просто удалить все /etc/logrotate.d/upstartи повернуть файлы отдельных сервисов по отдельности. Поскольку directory ( /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-команда шумит - и вы не хотите, чтобы такой шум отправлялся вам по электронной почте cron. Обратите внимание, что я не перенаправляю stderrтуда, только stdout- если есть проблема, вы все равно получу твой e-mail об этом.)