Wer bereits die neuesten Fedora-Versionen 19 (Beta) und 20 austestet, sollte sich sofort vergewissern, ob er auch von einem Bug im Logging-Service betroffen ist, der die Festplatte binnen kürzester Zeit mit Logfiles überschwemmt. Lüfterlose Hardware ist gar vom Hitzetod bedroht.
Wie Adam Williamson in seinem Blog und auf der Fedora-Mailingliste beschreibt, führt das Update auf Version 7.4.0.1 des Rsyslog-Daemons dazu, dass Fedora-19- und -20-System gigabyteweise Daten in die Logfiles schreiben und dabei die CPU-Last auf permanent 100 Prozent hochgeht.
Workaround
Schnelle Abhhilfe schafft ein sofortiges “systemctl stop rsyslog.service” und ein folgendes Downgrade auf die Vorgängerversion von Rsyslogd, die bis heute morgen ihren Dienst verrichtete, mit “yum downgrade rsyslog”. Außerdem sollten Anwender bis zu einer Lösung des Problems den Eintrag “exclude = rsyslog*” in die Datei “/etc/yum.conf” hinzufügen. Wer aber – entgegen aller Warnungen – FC 19 oder 20 bereits auf produktiven Systemen einsetzt, sollte sich den Blogpost von Williamson komplett durchlesen, sonst droht ihm ein Datenverlust bei den kritischen Logfiles. Adams Anleitung schildert die Workarounds ausführlich und zeigt, wie sich die großen Dateien sicher entfernen oder bereinigen lassen.
Bug #974335
Gleichwohl scheint das ganze Prozedere jedoch nur ein Workaround zu sein, denn das Problem liege tiefer, meint Williamson und verweist auf Fehler in Journald und Systemd. Der von Williamson angelegte Bug trägt die Nummer #974132. Dabei läuft das Logfile mit sich ständig wiederholenden, veralteten Log-Einträgen voll – so schnell das System kann und bis die Platte voll, der Akku leer oder die Maschine einen Hitzetod gestorben ist.
Update (1) : Wer dafür sorgen möchte, dass das den Fehler auslösende Rsyslog-Update aus den Update-Repositorys entfernt wird, der gebe ihm hier ein negatives Karma. Der zuvor in dieser News verlinkte Bug Report #974335 wurde mittlerweile als Duplikat von #974132 gekennzeichnet.
Update (2): Auf manchen Systemen scheint es auszureichen, die (binären Logdaten in den) Dateien unter “/var/log/journal” zu löschen. Einige Testsysteme laufen damit seit mehreren Stunden stabil, auch mit der neuen Rsyslog-Version.





Wir vom rsyslog-Projekt haben auch reagiert und in das imjournal Modul die – eigentlich überflüssige – Möglichkeit zur Reduzierung der Meldungsrate eingebaut. Unsere Stellungnahmen mit weiteren Massnahmen findet sich hier:http://blog.gerhards.net/20…