Upstart öffnet Protokolldateien bei der Protokollrotation nicht erneut

Upstart öffnet Protokolldateien bei der Protokollrotation nicht erneut

Wir verwenden upstart, um unsere Dienste auf unseren Ubuntu-Servern zu verwalten. Sie erstellen Protokolle, die in /var/log/upstart/SERVICE_NAME.log protokolliert werden.

Anschließend werden die Protokolldateien täglich mit dem in 12.04 LTS enthaltenen Logrotation-Skript rotiert:

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

Das Problem besteht darin, dass logrotate zwar die Dateien verschiebt, Upstart jedoch kein Signal zum Schließen und erneuten Öffnen der Dateien sendet, sodass der Upstart-Prozess in eine Lösch-PID schreibt.

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 

Natürlich könnte ich die Ausgabe meiner eigenen Dienste in andere Protokolldateien umleiten, aber das Problem für die Systemprozesse wäre immer noch da. Außerdem möchte ich nicht mehr Infrastruktur aufbauen müssen, als ich brauche.

Antwort1

Ich glaube, Sie haben drei Möglichkeiten.

  1. Sie ändern die bestehende Konfiguration durch Hinzufügen von "copytruncate"

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

  2. Wenn Sie die vorhandene Logrotate-Konfiguration nicht ändern können oder dürfen, weil andere Protokolldateien nicht darunter leiden und die vorhandene Konfiguration für sie funktioniert, verschieben Sie Ihre „SERVICE_NAME.log“-Dateien bei Bedarf in einen neuen Ordner unter /var/log, erstellen Sie mit „copytruncate“ eine neue Konfiguration und fügen Sie sie zu cron.daily hinzu.

  3. a) Wenn Sie die Logrotate-Konfiguration des Host-Betriebssystems nicht ändern oder zu cron.daily des Host-Betriebssystems hinzufügen dürfen, besteht Ihre dritte Möglichkeit darin, die Skripte oder Programme so zu ändern, dass vor dem Schreiben in die Datei geprüft wird, ob die Datei vorhanden ist. b) Eine andere Möglichkeit ist ein Auszug aus Punkt 2 oben, nämlich Ihre Protokolldateien an einen anderen Ort zu verschieben und in Ihrem Skript oder Programm den für die Protokolldatei dieses Programms spezifischen Logrotate-Befehl auszuführen.

Punkt 3b oben ist schwieriger, aber eleganter, und ich verwende ihn die meiste Zeit, da er bedeutet, dass das Programm autark und selbstverwaltet ist und nicht von den Aufgaben des Betriebssystems überwacht werden muss.

Um herauszufinden, wie Sie logrotate manuell ausführen und zu Ihrem Programm oder Skript hinzufügen, geben Sie einfach ein:

man logrotate

oder

logrotate --help

Wenn Sie Python für Ihre Programme verwenden, können Sie nachsehen, wie dieses Programm es zur Selbstverwaltung seiner Protokolldateien nutzt. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Antwort2

Es stellte sich heraus, dass dies ein bekanntes Problem ist und dieFahrkartebleibt geöffnet, während ich dies schreibe.

Das Richtige ist wahrscheinlich, die /etc/logrotate.d/upstartkomplett zu entfernen und die Dateien der einzelnen Dienste einzeln zu rotieren. Da das Verzeichnis ( /var/log/upstart/) nur die stdout/stderr der verschiedenen Dienste enthält - und keinen Dienst, der alsDaemonsollte überhaupt auf diesen beiden Kanälen ausgegeben werden. Außer vielleicht ganz beim Start.

Auf den Systemen, die ich verwalte, werden von Upstart drei Dienste ausgeführt: php5.6-fpm, php7.1-fpm, und acpid. Keines der drei Protokolle ist aktiv, aber manchmal wird FPM neu gestartet, da seine Hauptprotokolldatei ( /var/log/php5.6-fpm.log) rotiert wird – und das verursacht dieses Geräusch, weil es beim Start irgendwelchen Unsinn ausgibt.

Wenn Sie trotzdem darauf bestehen, diese Dateien zu rotieren, können Sie sich darauf verlassen, dass ihre Namen mit den Namen der Dienste übereinstimmen und das folgende postrotateSkript verwenden:

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

Damit das oben genannte funktioniert, stellen Sie sicher, dassnichtverwenden Sie dort das sharedscriptsVerb – mein Scriptlet verlässt sich darauf, dass ihm der tatsächliche Pfad zur Datei als erstes Argument ( $1) übergeben wird.

(Die Umleitung dorthin /dev/nullist sinnvoll, da serviceder Befehl „-command“ laut ist – und Sie möchten nicht, dass Ihnen derartige Störungen per E-Mail von cron zugeschickt werden. Beachten Sie, dass ich nicht stderrdorthin umleite, sondern nur stdout– falls ein Problem auftritt, erhalten Sie trotzdem eine E-Mail darüber.)

verwandte Informationen