Systemd : The Revenge of Mariadb III

Ich möchte Euch heute eine kleine Weihnachtsgeschichte erzählen, die sich so im Linux Lande Fedora zugetragen hat. Um diese Geschichte zu verstehen, solltet Ihr Euch in diese Vorgeschichte von Mariadb eingelesen haben. Die Geschichte wird Euch lehren, Euch nicht mit dem SystemD anzulegen, denn er wird Euer Ende sein ..

Also, sprach der Admin …

Es ist mal wieder kurz vor Weihnachten. Der erste Schnee fiel schon auf den Boden, da trug es sich zu, daß ein älteres Fedora-System ein Upgrade brauchte. Also hisste der Admin die Wartungsflagge des Servers und begab sich an die Konsole. „Hmm..“  sprach zu seinem Monitor, „der Server ist alt, und wir könnten zwei Versionen überspringen, und damit viel Zeit sparen.“ Auf dem Monitor lächelte ihn seine Reflektion erfreut an und so ward dnf beauftragt, die OS-Release um zunächst zwei Stufen anzuheben.

Dnf tat wie ihm befohlen und ackerte um die gewünschten Pakete zu installieren. Nach 20 Minuten, war das Werk getan und der Admin beauftragte den Server sich neu zu starten. Er tat wie befohlen.

Nach dem Reboot, ist vor dem nächsten Reboot

In freudiger Erwartung, loggte sich der Admin wieder auf seinen Server ein. Tomcat lief, Cron lief, die Datenbank… lief.. und so startete der Admin die Post-Reboot Prozeduren, um die neue MariaDB Version zu initialisieren, das PHP zu setupen, die Chroot zu füllen und sich seinem eigentlichen Ziel, dem DNS Server zu widmen.

Nach einiger Zeit sagte sein treuer Freund pstree erstaunt zu Ihm : „Aber oh Herr, siehe. Der PowerDNS will nicht antworten, obwohl er läuft.“ Der Admin war geneigt an einen kleinen Post-Upgrade Bug zu glauben und startete den PowerDNS neu. Aber auch das zeigte keine Wirkung. Der Prozess blieb stumm. Wieder war es pstree, das aufgeregt zu ihm rief:  „Meister, Mariadb läuft gar nicht, wie soll PowerDNS da antworten?“

Und so befahl der Admin dem SystemD MariaDB neu zu starten. Er tat wie ihm geheißen, kehrte aber nicht von seinem Auftrage zurück. Auch nach 5 Minuten, blieb der SystemD auf dem Wege der Arbeit verschollen. Unruhe machte sich beim Admin breit. Wieso kam SystemD nicht von seinem Job zurück? Was konnte ihm nur passiert sein?

Auf der Suche nach dem Timeout

Also fragt der Admin den journald, was denn dem Systemd zugestoßen sein könnte. Aber der journald wußte es nicht. Ihn hatte keiner einen Fehler gemeldet. Unterdessen meldete sich pstree und sagte: „Herr, so freue Dich. MariaDB ist wieder da. Und PowerDNS antwortet auch wieder! “ . Der Admin schaute auf den Monitor und brummte ein „Hmmmm“ vor sich hin, als der Job endlich zurück kam. Aber was war das ? Weder MariaDB noch PowerDNS funktionierten noch.

Ein schnelles „systemctl status mariadb“ zeigte nur einen „Fehler 203/Exited“ an, und meinte es sei per Signal beendet worden. Wieder dieses „hmmm“ , diesmal von Reflex auf dem Monitor. „Danke“, sagte der Admin laut. pstree sprang aufgeregt durch die Konsole, nichts ging mehr, das war zuviel für ihn. „Komm wieder runter Tree, ich starts nochmal“. Aber auch das brachte nur das gleiche Ergebnis.

Der SystemD war, oder?

Dann durchfuhr es den Admin wie einen Blitz: „Das ist das verdammte Prozesslimit vom SystemD! Das wars doch beim letzten mal auch !“ Gesagt, geändert. Kein Erfolg! Der Admin wurde nervös. Tree hatte sich bereits in die weit entfernteste Konsole zurückgezogen. „Wir haben doch damals eine eigene Limit.conf gemacht.. wo war die nochmal .. ach ja, /etc/systemd/system/mariadb.d/ … könnte es sein, daß sich das Servicefile geändert hat und jetzt irgendeinen Timeoutmist macht ? “ murmelte der Admin zu seinem Abbild auf dem Monitor.

Ein kurzes „diff /usr/lib/systemd/system/mariadb.service /etc/systemd/system/mariadb.service “ erhellte die Mine des Admin.. „JA, DAS WARS“. Endlich. Das eigene Unitfile war derart veraltet, weil es für zwei OS Releases früher gemacht war, daß der Systemd einen falschen Weg zum Start einschlagen mußte. Als der Admin das File entfernte und den Dienst startete, sprang Tree jubilierend aus seiner Konsole. Es war geschafft !

Merke, wenn es um MariaDB geht, versteht der SystemD keinen Spaß. Also halte Dich immer an die Anleitung, wenn Du die Limits konform einbauen willst. Außerdem: MariaDB macht immer nur Ärger beim Update ! Aber wieso immer zu Weihnachten ??!?!?! 😀

 

Linux – mysqldump sieht Leerzeichen als leeren Datenbanknamen an

Erinnert Ihr Euch noch an diesen Beitrag : Solution – mysqldump – No database selected when selecting the database aus dem Jahr 2016 ?

MariaDB & mysqldump

Damals stolperte ich über einen Fehler im Kommandozeilenparsing von Mysqldump.

Wie sich herausgestellt hat, konnte der Betreuer Michael Scholm bei Redhat die Ursache für das Problem entdecken. Kommt Ihr nie drauf: Das  war Schuld ! Oh ?! Ihr habt es nicht gesehen, hier nochmal  . Vielleicht mit der Lupe, da: > <. Ein Space.  Hier … zwischen dem „usr/bin/mysqldump“ und dem „–addlocks“ ist ein “ “ zuviel drin:

/usr/bin/mysqldump  --add-locks -e --force -R ....

Da es keine Option ist, wird es tatsächlich als valider Versuch, einen Datenbanknamen anzugeben gewertet.IMHO, ein Parser-Logik-Bug. Redhat sieht das anders: „not a bug“. Da jetzt raus ist, was es verursacht, kann man es ja leicht beheben.

etwas Kontext

Die Parser für Linux sind, sagen wir mal, ein bisschen eigen und deren Interpretation auch. Als Trenner zweier Argumente einer Kommandozeile gilt ein freistehendes Leerzeichen. Die Bash-Shell entfernt doppelte Leerzeichen und setzte ein Leerzeichen an die Stelle. So ein Leerzeichen zu viel ist schnell getippt und würde zu vielen „Dicke Finger-Syndrom“-Problemen führen, weil ..

… Ja, weil der Parser ohne diesen Trick, zwei Leerzeichen in Folge so übersetzen :

ls -la  foo => ls -la "" foo

Weil „Leerzeichen“ sind Trenner, also steht da oben eigentlich: „ls{Trenner}-la{Trenner}{Trenner}foo .

Wenn man aber zwischen den Trennern nichts hat, dann kommt ein leeres Argument raus. Was ein leeres Argument bedeutet, zeigt sich hier im Beispiel:

[marius ~]$ ls -la "" foo
ls: Zugriff auf '' nicht möglich: No such file or directory
ls: Zugriff auf 'foo' nicht möglich: No such file or directory

Wie man sehen kann versucht ls tatsächlich auf aka. „“ zuzugreifen. Wie das gehen soll ? Gar nicht. Ist ein Logikbug im Kontext von ls . Es wiederspricht der Natur eines ls , etwas aufzulisten, das es nicht gibt. Ergo müßte das Argument ignoriert werden. Jeder Mensch würde das so machen. Computerprogramme sind in der Beziehung blöde. Deswegen gibt es die Bash, die das Doppel-Leerzeichen wegnormaliziert und so vorhersehbare Fehler vermeidet, weil ..

Fehler vermeiden

wie man im obigen ls Beispiel gesehen hat, kann man es ja explizit angeben, wenn man muß => „“ oder “

MariaDB zieht sich jetzt auf den Standpunkt zurück, daß mysqldump sich ja nur wie ls verhalten würde. Tut es natürlich nicht, weil mysqldump komplett failed, wo ls einfach weitermacht und einen Fehler ausgibt.  Naja, Nobodys perfect.

Update

… oh, Redhat hat die Meinung geändert und einen Featurerequest bei MariaDB für einen besseren Parser erstellt. \o/ Das gibt einen dicken Daumen rauf! Mal sehen wies bei MariaDB ausgeht.

Ein MCP namens SystemD

Bunte Linien kreisen vor meinen Augen und bilden bunte Muster. Die Augen schmerzen. Der Kopf schmerzt und auch das Gehirn hat Schaden genommen. Die Welt ist dunkel, aber bunt.  Ich öffne die Augen. Ein rötlich strahlender Wächter stößt mich mit einer Energielanze an: „Aufstehen, Programm!“ Er will, daß ich mit ihm komme. Wir beschreiten Wege aus Energie… bunter Energie, seltsam neonfarbend und doch schwarz, wie die Nacht. Unterwegs treffen wir andere „Programme“ mit Ihren „Wächtern“. Bald stehe ich vor einem Kopf aus Licht: Der MCP, es gibt ihn wirklich!!!!!!

Verstört wache ich auf. Ein Computeradminalptraum, mitten am Tag, vermutlich am Keyboard eingenickt. Aber was könnte mir so einen Schrecken eingejagt haben, daß ich davon einen Tron .. ähm… traum hatte ?

Es fällt mir wieder ein, ich war grade dabei den Beitrag „Revenge of MariaDB“ Part II zu schreiben. Ja, MariaDB, was war doch gleich … achja.. ging mal wieder nicht nach dem Wechsel von F23 auf F24. Einer unserer Datenbankserver  macht merkwürdige Dinge. Die Webanwendung produzierte sporadisch „Kann nicht in die Datenbank verbinden“ Fehlermeldungen und brachte damit die QA vom Kunden an den Rand des Nervenzusammenbruchs.

Die Analyse geschaltete sich schwierig, weil die Admins immer erst nach einem Vorfall gerufen wurden, aber da ging es wieder. Erst eine zeitnahe Analyse des Netzwerkverkehrs bracht dann den ersten Hinweis: „Can’t create a new Thread. If you have enough free memory, check if … “

Damit konnte man etwas anfangen, ein Blick in eine spezielle Überwachungsdatei brachte dann den Hinweis, daß statt 40.000 Datenbankprozessen, nur wenige Hundert liefen. Also half nur ein Testlauf, mit einer Software, die Verbindungen in die Datenbank aufbaut und offen hält. Sowas kann man schnell in PHP, Perl oder Java schreiben:

import ordb.*;

public class Test {

    public static void main(String[] args) {

        Httpd[] liste = new Httpd[100000];
        for(int i=0;i< Integer.parseInt( args[0] );i++) {
            System.out.println("i="+i);
            liste[i] = new Httpd();
        }
        try {
            Thread.sleep(30000);
        } catch(Exception e) {

            e.printStackTrace();
            System.out.println(e);
        }

    }

}

In einer zweiten Konsole, kann man dann den Datenbankserver überwachen :

strace -e send,read,write -s 1024 -f -p `pidof mysqld`

Damit hat man alle Datenbankserverinstanzen im Blick, was die so Lesen und Schreiben und tatsächlich bestätigte dies den Anfangsverdacht, daß der Datenbankserver nicht genug Prozesse spawnen kann. Er setzte bei 512 Prozessen aus, viel zu wenig für unsere Anwendung.

Der schwierige Teil : Limits prüfen

Als erstes denkt man natürlich, daß sich bei den Limits aus Systemd und die Limits : The Revenge of Mariadb etwas geändert hätte, hatte es aber nicht. Wenn man das OS updatet können aber noch ganz andere Dinge passieren, also muß man hier nach „neuen“ Limits suchen.  Um überhaupt die Limits eines Prozesses Live einsehen zu können, muß man ins /proc/ eintauchen:  cat /proc/`pidof mysqld`/limits

Das kann dann so aussehen:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            unlimited            unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             unlimited            unlimited            processes 
Max open files            65536                65536                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       32195                32195                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

Dummerweise sagt dies genau, was man nicht hören will: Alles ok, es gibt keine Limits bei den Prozessen.

Und jetzt steht man da, wo zum Geier kommt dieses 512 Prozesse Limit her?

Es gibt eine Datei namens:  /etc/security/limits.conf

In der könnte man Limits für User eintragen, was aber nicht der Fall war. Außerdem wäre das in der Auflistung genau dieser Limits aufgefallen. Wo kommt dann das Limit her ?

An der Stelle muß man dann praktisch zu Denken anfangen, weil Docs lesen bringt einen fast nicht weiter, weil man gar nicht damit rechnet, daß es noch mehr Limitmöglichkeiten gibt, also auch nicht weiß in welcher Richtung man suchen sollte. Ein gesunder Pragmatismus ist jetzt hilfreich, vielleicht wars auch eine Verzweiflungstat :  grep -r 512 /etc/ /proc/sys/

Also in allen Dateien von ETC und PROC nach einer EIntragung mit 512 zu suchen. Und genau das hat zum Erfolg geführt, so daß ich jetzt eine Anklage wegen Ruhestörung und einen Abdruck meiner Hand an der Stirn habe 😀

Der SystemD macht mehr als er sollte

Im SystemD gibt es eine Konfigurationsdatei : /etc/systemd/system.conf

Der Auslieferungszustand bei Fedora ist, daß dort alle Werte auskommentiert sind, also ungültig sind. Dort fand sich eine 512 Eintragung und der Name der Option war … DefaultTasksMax=512 !

Aber die Option war abgeschaltet, also ist doch die erste Annahme, daß es kein Limit gibt, oder? Tja, Pech gehabt! Der Wert ist nur Deko, weil als Default in den SystemD einkompiliert 🙁

Zum Glück kann man den Wert in dieser Config ändern, den SystemD + MariaDB neustarten und dann wird der neue, unlimitierte Wert auch übernommen. Er taucht in keiner ( mir bekannten ) Procdatei auf. (Hinweise willkommen)

Alles in allem eine Änderung die wohl zu einer heftigen Reaktion seitens der Betroffenen geführt hat, weil die Systemd Entwickler das in einer neueren Version auf 15% der möglichen Prozesse eines Systems limitiert haben. In  unserem Fall wäre das noch schlimmer gewesen, weil wir so noch schlechter hätten Debuggen können, weil es sehr viel seltener passiert wäre.

Warum gibt es das Limit überhaupt ? Ja, weil es Bomben gibt. Das sind z.b. Bashscripte die sich selbst starten und dabei von der Shell abforken, so daß nach kurzer Zeit alle Resourcen eines Systems aufgebraucht sind. Hackt man also einen Server, könnte man den so intern dosen. Damit das nicht geht, gibt wenigstens ein Limit 😉 Das mal jemand Fedora als Server benutzt und dann auch noch als High Performance, damit hatte wohl niemand gerechnet 😀

Meiner Meinung nach, sollte sich der SystemD auf das Starten von Programmen konzentrieren, denn da ist er bedingt besser als SystemV. Aber die ganzen anderen Anmaßungen die das Teil so vornimmt, sind nicht so schön. Der SystemD kann einen echt fertig machen 😉

Ich bin mal gespannt, was beim nächsten OS Upgrade auf uns wartet 😉

Noch keine Patches für MariabDB Root Exploits vorhanden

Für die u.a. bei The Hacker News gemeldeten Root-Exploits für MariaDB gibt es noch keine Patche im Fedora Repository, auch nicht im Unstable Bereich. Da hilft nur, den möglichen Exploit durch Verschleierung zuvermeiden.

Der bereits verfügbare Testexploit, legt Dateien im /tmp/ Ordner an. Das kann man schon mal verhindern, indem beim Start mit Systemd ein privates Temp-Verzeichnis benutzt wird. Das verhindert den Hack nicht, aber die kleinen Scriptkids werden an der Hürde scheitern 😉

Wenn man sein mariadb.service File nicht geändert hat, kommt es in Fedora bereits mit der richtigen Einstellung:

[Unit]
Description=MariaDB 10.0 database server

# Place temp files in a secure directory, not /tmp
PrivateTmp=true

In der my.cnf sollte man sowieso immer das Benutzen von Symbolischen Links abschalten, eine Serverdatenbank braucht das i.d.R. nicht:

symbolic-links=0

Damit kann man auch ohne Patch CVE-2016-6662 nicht ausnutzen um seine Rechte zu eskalieren. Wer bislang „mariadb-10.0.27-1“ noch nicht eingespielt hat, sollte das trotzdem dringend nachholen.

Gegen die Lücken CVE-2016-6663 und CVE-2016-6664 sind die Patche bei Fedora noch in Arbeit. Leider ist auch im Koji noch keine Testversion ersichtlich. Die letzten Builds stammen vom Anfang des Monats, welche zudem die CVE Patche nicht enthalten. Dies kann natürlich daher rühren, daß diese Versionen nicht anfällig waren, da es sich um den 10.1.17/18 er Zweig von Mariadb handelt.

2038 ist schneller da als man denkt

In 23 Jahren, wenn die Unixwelt Y2K erlebt, wird die Welt zusammenbrechen.

Wir haben ja jetzt 2015 und die gängigste Datenbank MySQL legt Timestampfelder immer noch als 32-Bit Feld an. Es sollte ja eigentlich kein Problem sein dort intern 64-Bit zu benutzen, aber wie das so ist, die Tücke liegt im Detail.

MySQL speichert die Daten in einer großen Datei im Binärformat. In dem Augenblick wo dieser Feldtype auf 64-Bit umgestellt wird, muß zwangsweise mysql_upgrade laufen, sonst gibt es nur Probleme. Und wie das Leben so spielt,  mysql_upgrade wird bei normalen Updates eigentlich nie ausgeführt. Da muß man als Admin selbst machen.

„Wenn das noch 23 Jahre sind, warum nervst Du jetzt schon rum?“

Ich kenne Euch halt 🙂 Dabei wollte ich auf etwas anderes hinaus:

Führt öfter mal mysql_upgrade durch. Erst dieser Befehl schreibt die Strukturen im Mysql um z.b. wenn neue Felder in der „mysql“ Datenbank hinzugekommen sind. Mit den Updates von Fedora 20 auf 21 z.b. mußte so ein mysql_upgrade auch zwangsweise laufen, wenn man die neuen „Features“ benutzen wollte.

Zurück zum Jahr 2038. Es werden dann mehr als 40 Jahre zwischen den Leuten liegen, die Y2K mitgeplant haben und denen, die dann für die Systeme verantwortlich sind. Da darf man annehmen, daß die meisten das auf die gleiche leichte Schulter nehmen werden, wie Ihre Vorfahren.

Deswegen wünsche ich heute schon einen schönen Weltuntergang 😉