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 !