☰

Upstart не открывает повторно файлы журналов при ротации журналов

tag-icon • tag-icon upstart init logrotate
Upstart не открывает повторно файлы журналов при ротации журналов

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

Затем ежедневно файлы журналов ротируются с помощью скрипта logrotation, который входит в состав 12.04 LTS:

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

Проблема в том, что пока logrotate перемещает файлы, он, по-видимому, не подает сигнал upstart закрыть и снова открыть файлы, в результате чего процесс upstart записывает в 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

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

решение1

Я думаю, у вас есть три варианта.

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

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

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

man logrotate

или

logrotate --help

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

решение2

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

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

На системах, которыми я управляю, upstart запускает три службы: 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-command шумит, а вы не хотите, чтобы cron присылал вам такой шум по электронной почте. Обратите внимание, что я не перенаправляю stderrтуда, только stdoutесли возникнет проблема, вы все равно получите о ней письмо.)

Связанный контент