Logrotate Problem täglich 00:00 Uhr

[weltmeister]

Täglich um 00:00 Uhr "verabschiedet" sich der Logrotate-Dienst auf einigen Servern unter Debian 10. Leider sind die Logeinträge nicht gerade besonders hilfreich:

Nov 4 00:00:07 s5 rsyslogd: [origin software="rsyslogd" swVersion="8.1901.0" x-pid="560" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
Nov 4 00:00:07 s5 systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 4 00:00:07 s5 systemd[1]: logrotate.service: Failed with result 'exit-code'.
Nov 4 00:00:07 s5 systemd[1]: Failed to start Rotate log files.

Hat jemand einen Tipp, wo man zuerst mit der Fehlersuche beginnen könnte?

[antondollmaier]

Logrotate manuell ausführen (logrotate -v -f /etc/logrotate.conf)

[weltmeister]

Logrotate manuell ausführen (logrotate -v -f /etc/logrotate.conf)

...ist perfekt duchgelaufen. Wie aber kann man das Problem lösen, das sich der Dienst von selbst beendet?

[TCRserver]

Wenn ich es noch richtig im Kopf habe, dann war es irgendwas im Zusammenspiel mit dem syslog^bzw. dem postrotate Befehl.
Betroffen waren bei uns nur Systeme die ein Debian 9 auf 10 Upgrade bekommen haben.

So aus dem Kopf raus:
Edit: /etc/logrotate.d/rsyslog

suche nach:

        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript

und ersetze durch:

        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript

Aber wirklich aus dem Kopf raus und ohne Gewähr!

[weltmeister]

Vielen Dank, den Eintrag

postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript

gibt es so in der gen. Datei nicht. Da das Problem leider noch immer besteht: wo könnte man noch nach der Ursache suchen?

[antondollmaier]

Laut erstem Beitrag kam es zu Fehlern im logrotate.service.

Daher: "journalctl -u logrotate.service" aufrufen und prüfen, ob es dort Einträge gibt. Ggf. auch tatsächlich bis 00:00 Uhr warten und im "journalctl -f" mitverfolgen, was so passiert.

Spannend empfinde ich jedoch, dass Logrotate überhaupt um 00:00 Uhr läuft. Standard ist eigentlich 06:25 Uhr für die Dailys.

[weltmeister]

Hier die 3 Einträge von heute:

Nov 06 00:00:05 s20.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 06 00:00:05 s20.de systemd[1]: logrotate.service: Failed with result 'exit-code'.
Nov 06 00:00:05 s20.de systemd[1]: Failed to start Rotate log files.

In den Logfiles steht das selbe. Aber klug werde ich daraus nicht.

[weltmeister]

Habe das Problem einmal einem erfahrenen Administrator weitergereicht, hier dessen Antwort:

Wenn ich mir die Fehlermeldung von lograte ansehe:

systemctl status logrotate
● logrotate.service - Rotate log files
  Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
  Active: failed (Result: exit-code) since Thu 2020-11-12 00:00:01 CET; 9h ago
    Docs: man:logrotate(8)
          man:logrotate.conf(5)
 Process: 25679 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
Main PID: 25679 (code=exited, status=1/FAILURE)

Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web4/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web5/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web6/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web3/logs/*.log '
Nov 12 00:00:01 s26.server.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 12 00:00:01 s26.server.de systemd[1]: logrotate.service: Failed with result 'exit-code'.Nov 12 00:00:01 s26.server.de systemd[1]: Failed to start Rotate log files.

wird klar das es am postrotate Kommando "/usr/bin/killall -HUP lclogsplit" in der Datei: /etc/logrotate.d/liveconfig-vhosts liegt.
Dieses Kommando killt das Programm lclogsplit für jedes Dort angegebene Verzeichnis Abschnitt.
Da schon beim ersten Aufruf der lclogsplit Daemon nicht mehr läuft, werden alle Folgeaufrufe mit Error 1 an das posttrotate zurückgegeben, was dann zu dieser Meldung führt.

Hier müssten Sie einmal an den Anbieter von Liveconfig herantreten ob es diesbezüglich ein Update/Patch gibt. Da das logrotate file aus liveconfig generiert wird, bringt es leider nichts es dort selbst zu beheben, da es immer wieder überschrieben wird.

[kk]

Das Problem liegt wahrscheinlich ganz woanders, das hier beschriebene Verhalten vom logrotate ist lediglich ein Symptom.

Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web4/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden

Das zeigt, dass der lclogsplit-Prozess überhaupt nicht lief, als logrotate ausgeführt wurde. Da lclogsplit aber i.d.R. als Child-Prozess vom Apache gestartet wird, scheint da schon irgendwas nicht zu stimmen.
(Ausnahme: beim Dual-Betrieb von Apache und NGINX läuft lclogsplit als eigenständiger Daemon)
Hier wird übrigens ein HUP-Signal gesendet, der lclogsplit-Prozess wird dadurch also nicht beendet, sondern lediglich darüber informiert dass diese prüfen soll, dass Log-Dateien eventuell rotiert wurden.

Wir können die logrotate-Konfiguration dahingehend ändern, dass der Exit-Code des postrotate-Scripts (also der killall-Aufruf) ignoriert wird. Das dürfte das von Ihnen beschriebene Symptom beseitigen, aber nicht die Ursache beheben.

Viele Grüße

-Klaus Keppler

[weltmeister]

Vielen Dank für die Erläuterungen! Hierzu weitere eingehende Fragen:

Was könnte der Grund dafür sein, dass der lclogsplit-Prozess nicht läuft?
Gibt es eine Möglichkeit, diesen manuell zu starten oder gar neu zu installieren /zu aktivieren?
Hat dieser Dienst Konfigurationsdateien, die man auf Richtigkeit / vorhandensein prüfen kann?

Das Problem tritt auf insgesamt 7 Servern auf, die kürzlich von Debian 9 auf 10 aktualisiert worden sind. Ich wäre sehr daran interessiert, diese aus der Welt zu schaffen.