Upstart nie otwiera plików dziennika podczas logrotacji

Używamy upstart do zarządzania naszymi usługami na naszych serwerach Ubuntu. Tworzą dzienniki, które są wylogowane na /var/log/upstart/SERVICE_NAME.log

Następnie codziennie pliki dziennika są obracane za pomocą skryptu logrotation, który jest dostarczany z 12.04 LTS:

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

Problem polega na tym, że podczas gdy logrotate przenosi pliki, nie wydaje się, aby sygnalizował, aby upstart zamknął i ponownie otworzył pliki, pozostawiając proces aktualizacji zapisujący do PID usuwania.

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 

Oczywiście mógłbym przekierować dane wyjściowe z moich własnych usług do innych plików dziennika, ale problem nadal występowałby w przypadku procesów systemowych. Wolałbym też nie budować więcej infrastruktury niż potrzebuję.

Wierzę, że masz 3 opcje.

1. Modyfikujesz istniejącą konfigurację, dodając „copytruncate”

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

2. Jeśli nie możesz lub (nie możesz) zmienić istniejącej konfiguracji Logrotate z powodu innych plików dziennika, które nie cierpią, a istniejąca konfiguracja działa na nie, przenieś pliki „SERVICE_NAME.log” do nowego folderu w / var / log, jeśli chcesz, utwórz nową konfigurację za pomocą „copytruncate” i dodaj ją do cron.daily.

3. a) Jeśli nie możesz zmienić konfiguracji hosta os logrotate lub dodać do cron.daily systemu operacyjnego hosta, trzecią opcją jest zmiana skryptów lub programów, aby sprawdzić, czy plik istnieje przed zapisaniem do pliku. b) Innym sposobem jest trochę punkt 2 powyżej, który polega na przeniesieniu plików logów gdzie indziej, aw skrypcie lub programie, wykonaj polecenie logrotate specyficzne dla pliku dziennika tego programu.

Punkt 3b powyżej jest trudniejszy, ale bardziej elegancki i właśnie tego używam przez większość czasu, ponieważ oznacza to, że program jest samowystarczalny i samozarządzający i nie potrzebuje zadań systemu operacyjnego, aby go opiekować.

Aby dowiedzieć się, jak ręcznie uruchomić program logrotate i dodać go do programu lub skryptu, po prostu wpisz:

man logrotate

lub

logrotate --help

Jeśli używasz Python do swoich programów, możesz sprawdzić, w jaki sposób ten program używa go do samodzielnego zarządzania plikami dziennika. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Okazuje się, że jest to znany problem i bilet pozostaje otwarty podczas pisania.

Prawdopodobnie należy po prostu /etc/logrotate.d/upstartcałkowicie usunąć i osobno obrócić pliki poszczególnych usług. Ponieważ katalog ( /var/log/upstart/) zawiera tylko stdout / stderr różnych usług - i żadna usługa przeznaczona jako demon nie powinna w ogóle wysyłać do tych dwóch kanałów. Może z wyjątkiem samego startu.

Na systemach mam zarządzających, trzy usługi są prowadzone przez nowobogackich: php5.6-fpm, php7.1-fpm, i acpid. Żaden z trzech dzienników nie jest aktywny, ale czasami fpm jest restartowany ze względu na /var/log/php5.6-fpm.logobrót jego głównego pliku dziennika ( ) - i powoduje ten hałas, ponieważ generuje pewne nieprzyjemności podczas uruchamiania.

Jeśli mimo to nalegasz na obrócenie tych plików, możesz polegać na tym, że ich nazwy pasują do nazw usług i użyj następującego postrotateskryptu:

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

Aby powyższe zadziałało, nie używaj tam sharedscriptsczasownika - mój skryptlet polega na tym, że faktyczna ścieżka do pliku zostanie do niego przekazana jako pierwszy argument ( $1).

(Przekierowanie na /dev/nulljest przydatne, ponieważ service-polecenie jest głośne - i nie chcesz, aby taki hałas wysyłał ci e-maile przez crona. Zauważ, że nie przekierowuję stderrtam, tylko stdout- jeśli jest problem, ty Nadal otrzymam Twój e-mail.)