Systemd schickt alte Einträge zum Syslogd

Posted on by

Die Bild-Zeitung könnte mit der folgenden Schlagzeile öffnen:

„Systemd wahnsinnig – Syslogd kurz vor dem Zusammenbruch“

Wenn man einen Produktivserver im Netz hat, möchte man solche Schlagzeilen lieber nicht lesen, dennoch können Sie passieren. Mit den folgenden kleinen Anweisungen kann man das Desaster beenden.

Aber zunächst mal zum eigentlichen Problem:

Der Syslogd läuft mit 95% CPU Last, aber ansonsten ist auf dem System nichts zu sehen, was die Nachrichten produzieren könnte. Der erste Blick geht daher nach /var/log/messages:

Jul 16 20:21:01 systemd: Started Session 29860 of user root.
Jul 16 20:21:01 systemd: Starting Session 29859 of user munin.
Jul 16 20:21:01 systemd: Started Session 29859 of user munin.
Jul 16 20:21:01 systemd: Starting Session 29862 of user root.
Jul 16 20:21:01 systemd: Started Session 29862 of user root.
Jul 25 07:34:20 rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting

Was wir sehen, sind eine Flut von alten Nachrichten und die Meldung, daß imournal daran gehindert wurde, weitere Nachrichten zu loggen, weil es zu viele wurden. Was Sie oben nicht sehen ist, daß das Ganze mit Nachrichten aus April begonnen hat. 3,7 GB an Logfiles sollten nochmal durch den Syslogd gejagt werden.

Auch wenn die eigentlichen Nachrichten nicht mehr in /var/log/messages auftauchen, so verbraucht der Syslogd trotzdem noch eine Menge CPU Leistung, meistens soviel er bekommt.

Ein Neustart von syslogd machts nur schlimmer, weil die alten Nachrichten dann wieder ins Log geschrieben werden.

Die Lösung:

Man editiere /etc/systemd/journald.conf :

 [Journal]
 #Storage=auto
 #Compress=yes
 #Seal=yes
 #SplitMode=login
 #SyncIntervalSec=5m
 #RateLimitInterval=30s
 #RateLimitBurst=1000
 #SystemMaxUse=
 #SystemKeepFree=
 #SystemMaxFileSize=
 #RuntimeMaxUse=
 #RuntimeKeepFree=
 #RuntimeMaxFileSize=
 #MaxRetentionSec=
 #MaxFileSec=1month
 #ForwardToSyslog=yes
 #ForwardToKMsg=no
 #ForwardToConsole=no
 #TTYPath=/dev/console
 #MaxLevelStore=debug
 #MaxLevelSyslog=debug
 #MaxLevelKMsg=notice
 #MaxLevelConsole=info

in dem man das hier einfügt oder ändert, ganz wie Sie möchten:

[Journal]
 MaxRetentionSec=10day

Wenn man dann den Journaldienst des Systemd neustartet, werden alle alten Files aus /var/log/journal/ entfernt und der Systemd schickt nur noch 10 Tage Logs an den Syslogd. Das ist aber i.d.R.  in wenigen Sekunden durch und die Last des Systems geht auf normal zurück.

 systemctl restart systemd-journald

Als positiver Seiteneffekt werden gleich noch monatealte Logdaten gelöscht. In unserem Fall waren es satte 3 GB.

Das Ende der Orgie erkennt man im Logfile des Syslogds an dieser Meldung:

Jul 25 07:35:13 rsyslogd-2177: imjournal: 229963 messages lost due to rate-limiting

Das wäre früher oder vermutlich sehr viel später auch ohne die Anpassungen im in der journal.conf passiert.

Da aber nach 17 Minuten erst 1 Monat verarbeitet wurde, ist es aus Performancegründen des Servers ratsam das zu beschleunigen.

Fehlerhafte Updates rückgängig machen

Posted on by

Da mir grade das Problem in Form eines Spamassassinupdates begegnet ist, hier der Weg wie man so ein Update rückgängig macht.

Zunächst einmal muß man ermitteln wie das alte Paket hieß, also welche Versionnummer das war. Dazu kann man in das Yum.log schauen und nach dem vorletzten Update suchen:

grep spamassassin /var/log/yum.log

oder man benutzt einfach Yum selbst:

yum list --showduplicates spamassassin

Wenn es mehrere alte Pakete zur Auswahl gibt, kann man dann mit „yum erase“ und „yum install“ das alte Paket installieren.

Einfacher ist es allerdings, wenn man das mit „yum downgrade“ macht:

yum downgrade spamassassin

Damit wir die aktuelle Version des Pakets entfernt und die letzte Version installiert.

Was man beachten muß

Wenn man einen automatischen Updateprozess per Cron laufen hat, also z.b. „yum -y update“ alle 2 Stunden ausgeführt wird, installiert Yum sofort wieder das neue Paket. Daher muß man diesen Prozess  stoppen, oder das Paket auf die Sperrliste setzen.

Verräterlampe

Wie schon in einem früheren Artikel befürchtet, schreitet die Heimautomatisierung unaufhaltsam voran. Sie schreckt dabei auch nicht vor Geheimnisverrat zurück, wie ein aktuelles Beispiel zeigt.

Gestern wurde bekannt, daß LED-Lampen des Herstellers Lifx ein Sicherheitsproblem haben. Durch geschicktes Senden von WLAN Paketen an die Smarten LED-Lampen, kann ein Angreifer an das WLAN Passwort des verwendeten Netzwerkes gelangen. Das liegt darin begründet, daß sich die Lampen selbst vernetzen, so lange min. eine Lampe ins WLAN Netz einkonfiguriert wurde. Nötig ist das, damit man den Lampen der Handy App sagen kann, wie hell man es gern hätte.

Abhilfe schafft ein Firmwareupdate, aber mal ehrlich: Wer updated schon seine Deckenlampen ?

Quelle: http://contextis.com/blog/hacking-internet-connected-light-bulbs/