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

10

Мы используем выскочку для управления нашими сервисами на наших серверах 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 

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

    
задан Andrew Newdigate 10.06.2014 в 09:36
источник

2 ответа

2

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

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

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

man logrotate

или

logrotate --help

Если вы используете Python для своих программ, вы можете проверить, как эта программа использует его для самостоятельного управления файлами журнала. Ссылка

    
ответ дан DanglingPointer 12.06.2016 в 08:08
0

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

Правильная вещь, вероятно, состоит в том, чтобы просто удалить /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

Чтобы выше работало, убедитесь, что not использует sharedscripts глагол там - мой скриптлет полагается на факт, фактический путь к файлу будет передан ему в качестве первого аргумента ( ).

(перенаправление в /dev/null полезно, потому что service -команда является шумной - и вы не хотите, чтобы такой шум посылался вам по электронной почте cron. Обратите внимание, что я не перенаправляю stderr там, только stdout - если есть проблема, вы все равно получите свое электронное письмо об этом.)

    
ответ дан Mikhail T. 29.11.2017 в 21:04