Выскочка, не вновь открывшая файлы журнала на logrotation

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

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

10
задан 31 March 2015 в 05:06

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 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
ответ дан 23 November 2019 в 04:41

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

Правильный поступок должен, вероятно, просто удалить /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 глагол там - мой scriptlet полагается на факт, фактический путь к файлу будет передан ему как первый аргумент ($1).

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

0
ответ дан 23 November 2019 в 04:41

Другие вопросы по тегам:

Похожие вопросы: