[ENDLICH GELÖST] Logrotate bringt mich zur Verzweiflung

[pgs]

Hallo,

ich habe hier auf einer Maschine ein Problem mit logrotate. logrotate rotiert nicht, sondern lastet das System voll aus und muss dann gekillt werden.
Meine logrotate.conf ist die Standard-logrotate.conf, die Rechte stimmen auch:

Code: Alles auswählen

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

Ich habe zur Fehlersuche alle weiteren logrotate-configs in /etc/logrotate.d mal entfernt; an diesen liegt es also nicht.
Wenn ich nun logrotate manuell anstoße mit

Code: Alles auswählen

logrotate -v /etc/logrotate.conf

, so läuft er durch bis /var/log/btmp und hängt sich danach auf:

Code: Alles auswählen

soz-Fileserver:/# logrotate -v /etc/logrotate.conf
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config info for /var/log/wtmp 
reading config info for /var/log/btmp 

Und das war's, 100% Auslastung, nach zwei Tagen habe ich den Prozeß dann gekillt.
Die gleiche Konstellation läuft hier auf zwei anderen Maschinen übrigens einwandfrei.

Was zur Hölle kann das sein?

Grüße, pgs

[pgs]

So, ich konnte den Fehler jetzt systematisch eingrenzen. Logrotate hängt sich reproduzierbar nach dem Durchführen von /etc/logrotate.conf auf.

Logrotate liest also die Einträge (egal wieviele, und egal ob auf /etc/logrotate.d verweisen wird) und hängt sich dann auf. Das hat also nix mit /var/log/btmp zu tun, wie ich ursprünglich dachte. Dass diese Schritte im Debug die letzten ausgeführten waren, lag nur daran, dass sie eben auch die letzten in /etc/logrotate.conf waren...

Weiter gekommen bin ich damit nicht nicht. Was ist da nur los?

[pgs]

Neues: Egal, was man macht: logrotate hängt sich beim parsen von /etc/logrotate.conf auf. Egal, wie viel oder wenig da drin steht. Herrgott nochmal, bin ich der einzige in diesem Universum, bei dem dieses Problem auftritt? Scheiße, das ist ein Server, der produktiv läuft - was ist denn das für 'ne Art, jede Woche einmal Logdateien manuell zu löschen?

pgs

[pgs]

So, jetzt ist das Ding gelöst. Des Rätsels Lösung lag in /var/lib/logrotate/status. Hier schreibt logrotate für jedes Logfile einen Eintrag und geht das dann ducrh, um zu wissen, was wie rotiert werden muss.
Wir hatten vor einiger Zeit mal ein amoklaufendes Samba-Logging mit debug-Logfiles für jeden Client. Und in /var/lib/logrotate/status waren so um die 350000 Einträge. Und das hat den logrotate-Prozeß überfordert.
Datei gelöscht, Logrotate funktioniert.

Logrotate kommt also bei großen Logdateimengen ducrhaus an gewisse Grenzen.

mfg, pgs

[roth]

Grüß Gott,

helfen hätte ich Dir auch nicht können, weil die Konfiguration nicht ungewöhnlich, sondern richtig aussah und ja auch ist.

Herrgott nochmal, bin ich der einzige in diesem Universum, bei dem dieses Problem auftritt? Scheiße, das ist ein Server, der produktiv läuft - was ist denn das für 'ne Art, jede Woche einmal Logdateien manuell zu löschen?

Aber wie im richtigen Leben: einmal richtig geflucht und es funktioniert.


Gruß
Sven