Tag Archives: systemd

Systemd: wie man Journals sicher verkleinert

Posted on by

Privat wird man das Problem eher seltener anfinden, aber wenn man eine Linux Serverfarm betreibt, kommt es häufiger vor, daß Server wenig Platz auf den Platten melden. I.d.R. passiert das unabsichtlich, weil irgendwelche Logfiles oder selbstgebauten Sicherungssysteme der Kunden jeden Tag Daten auf die Platte kippen, welche die Kunden schon lange vergessen haben.

Bei der Suche nach Platz benutzt man auf einem Server eher selten Baobab, dafür meistens „du -sh /*|grep G“ .

Irgendwann bei der Suche, stolpert man über die großen Mengen Speicherplatz die in /var/log verwendet werden und hier ist i.d.R. der Syslogd der Platzkiller. Nun will man natürlich auch ältere Logs haben, damit darin nach Fehlern suchen kann. Insofern ist es ok, wenn die Logs etwas größer sind. Damit man aber schnell mal 2 GB Platz auf der Platte für andere Sachen gewinnt, kann man z.b. folgende Befehle benutzen:

journalctl --vacuum-time=10d
journalctl --vacuum-size=1G

Der erste Befehl löscht alle Logs, die älter als 10 Tage sind. Der zweite Befehl löscht alles weg, was mehr als 1 GB belegt. Ein 1 GB Log sollte für alle jüngeren Problemfälle reichen.

Jetzt könnte man die Größe des Logfiles in der Systemd Konfiguration dauerhaft hinterlegen, oder man nutzt den freien Platz nur temporär. Wenn man sich für letzteres entscheidet, darf man das Problem nicht auf die Lange Bank schieben, sondern sollte schnellstmöglich eine Entlastung der Platte durch Löschen anderer Daten herbeiführen.

Systemd Änderungen brechen langlaufende Prozesse ab

Für die Version 230 vom Systemd sind Anpassungen umgesetzt worden, die noch nicht alle Distributionen erreicht haben, aber jetzt schon Ihre Schatten vorraus werfen.

Das Defaultverhalten zu langlaufenden Prozessen wird geändert, was bedeutet, daß Prozesse, die per Screen(und anderen Tools) gestartet wurden, beim Logout des Users beendet werden. Screen ist aber gerade dafür da, daß man sich während der Prozess läuft, ausloggen kann,

Das neue Verhalten führte bei Debian bereits zu ersten Beschwerden der User. Zum Glück kann man das leicht abschalten:

Ladet die Datei /etc/systemd/login.d.conf in einen Texteditor und kommentiert die Zeile(n):

KillUserProcesses=no
KillOnlyUsers=
KillExcludeUsers=root

ein. Damit ist wieder alles wie vorher. ( A.d.R. ggf. ist ein Neustart des Loginds nötig, sprich ein Reboot )

 

 

Systemd und die Limits : The Revenge of Mariadb

Posted on by

Es hätte so ein schöner Tag werden können, Weihnachten ist grade rum, der deutsche Wetterdienst droht uns endlich mit Schnee und das Upgrade von Fedora 19 auf Fedora 20 lief gestern Nacht ohne Probleme ab. In freudiger Erwartung einer guten Meldung laß ich den morgendlichen Report meiner Serverfarm. Ok, es ist die Serverfarm meines Arbeitgebers, aber da ich mich morgens drum kümmern muß, ist es meine Farm. Mein System, meine Farm ! Pah.

Ich laß also im Bett die Emails der Nacht und alle Server schienen glücklich zu sein, nur einer meldete um 3 Uhr nachts über 500 Emails in seiner Mailqueue. Ein typischer Fall von Mailspam über ein gehacktes Mailkonto, doch dann wurde mir klar, es ist der Server der gestern sein Upgrade hatte und der hat gar keine Mailkonten die man hacken könnte. Mifft!

Einer ersten Analyse nach, liefen alle Dienste, schon mal ein gutes Zeichen. Dann schaute ich in das Logfiles des Mailserver und stiess auf eine große Anzahl von Fehlermeldungen, da der Mailserver nicht in den Datenbankserver einloggen konnte. Da aber die Emails über diesen Server angekommen waren, schien das nur ein temporäres Problem zu sein:

„gave DEFER: MYSQL connection failed: Too many connections“

Ohoh… nicht schon wieder.. In 2013 hatte wir nach einem Upgrade ein ähnliches Problem mit dem Httpd, der wollte nach Umstieg auf Systemd auch nicht mehr mit seinen Limits arbeiten. Zum Glück kann man das auf die gleiche Weise lösen, sollte man jedenfalls meinen.

Zunächsteinmal einen Blick in die /etc/my.cnf ob noch alles da ist, man weiß ja nie ..

[mysqld]
max_connections = 2000
max_join_size = 10M

noch alles da. Merkwürdig. Ein Blick ins Mysql-Logfile zeigte dann das hier :

10:26:15 [Warning] Changed limits: max_open_files: 1024  max_connections: 214  table_cache: 400

Das macht der liebe Mysqld, wenn das Open-Files-Limit nicht stimmt, denn Sockets sind auch nur Filedescriptoren. Aber moment, das hatten wir doch beim letzten Upgrade schon mal behoben! Wieso geht das nicht mehr ?

Ein Blick in /etc/systemd/system/mariadb.service zeigt uns: (u.a.)

[Service]
LimitNOFILE=1000000
Type=simple
User=mysql
Group=mysql

Da steht doch, daß er das Filelimit anheben soll, wieso tut er das nicht? Ab dieser Stelle haßte ich den Systemd wiedermal.. wie sich rausstellte, ist das Teil einfach großer „Mifft!“ wie Bernd sagen würde.

Es reicht nicht mehr, das NOFILE Limit ins eigene Servicefile zu packen, man muß es (auch noch) in einer eigenen Limitsdatei eintragen :

# cat /etc/systemd/system/mariadb.service.d/limits.conf 
[Service]
    LimitNOFILE=1000000

Wenn ich jetzt nostalgisch werde, müßt Ihr das verzeihen : Früher war alles besser !

Da gab es son Mist nicht. Der Systemd hat auch Vorteile, daß kann man nicht leugnen, aber für das Teil braucht man ein ganzes Handbuch, wo man vorher einfach mal „ulimit -n 100000“ im Initscript benutzen konnte und die Welt war wieder ok. Das war wirklich besser !