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 er 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. Ihm 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 ??!?!?! 😀

 

pathdiscover vorgestellt

Als Admin kennt man das, irgendein Programm will auf eine Datei zugreifen und es geht nicht. Da kommt pathdiscover ins Spiel. Das kleine Linuxtool aus Cyborgs Github-Repository macht Schluß mit dem ewigen Suchen. Es zeigt alle Pfadsegmente mit allen Rechten in einem Schritt an.

Die Ausgabe

Die Ausgabe wird am besten als vorformatierter Text angezeigt, kann sein, daß Ihr da jetzt mal etwas scrollen müßt:

# pathdiscover /home/wordpress/jetpack/

'/home/wordpress/jetpack/' translates to '/opt/root/home/wordpress/jetpack'

 4096 Bytes wordpress/wordpress drwxr-xr-x : jetpack   ( directory )
 4096 Bytes wordpress/services  drwxr-x--- : wordpress ( directory )
 4096 Bytes root/root           drwxr-xr-x : home      ( directory )
 4096 Bytes root/root           drwxr-xr-x : root      ( directory )
 4096 Bytes root/root           drwxr-xr-x : opt       ( directory )

Die Ausgabe kann man mit diversen Optionen anpassen, z.b. auch so, daß alle atime,ctime und mtime Zeitstempel angezeigt werden:

# pathdiscover -d /home/wordpress/jetpack/

'/home/wordpress/jetpack/' translates to '/opt/root/home/wordpress/jetpack'

 4096 Bytes (2013-10-29 15:24:51 | 2013-09-19 17:54:54 | 2017-12-06 06:30:20) wordpress/wordpress drwxr-xr-x : jetpack ( directory )
 4096 Bytes (2017-11-20 16:38:07 | 2017-11-20 16:38:07 | 2017-12-06 06:30:08) wordpress/services drwxr-x--- : wordpress ( directory )
 4096 Bytes (2017-11-09 10:34:50 | 2017-11-09 10:34:50 | 2017-12-06 03:58:54) root/root drwxr-xr-x : home ( directory )
 4096 Bytes (2017-09-01 22:09:15 | 2015-02-10 15:27:53 | 2017-12-05 22:45:02) root/root drwxr-xr-x : root ( directory )
 4096 Bytes (2017-09-01 22:16:29 | 2017-09-01 22:16:29 | 2017-12-06 03:58:39) root/root drwxr-xr-x : opt ( directory )

Die Optionen

Die Hilfe gibt folgende Programmoptionen aus :

pathdiscover [-a] [-d] [-h] [-n] [-V] <filename>

Die Optionen im Einzelnen …

-V gibt die Versionsnummer aus.
-n –names schaltet die Übersetzung von UID in Namen ab.
-N –numbers zeigt die Größe der Datei und Ordner in Bytes an, statt in „Größen“
-a –alternative zeigt den kompletten Pfad zu dem Segment an, statt nur den Segmentnamen
-d –full-time  fügt atime, ctime und mtime Ausgaben hinzu.
-NC  versucht erst gar nicht die Ausgabe zu formatieren, was z.b. den Einsatz von AWK und SED leichter macht.

Selbst kompilieren leicht gemacht

Da es sich im GITHUB um den rohen C-Sourcecode handelt, muß man das Programm selbst kompilieren, falls es nicht schon in einer Distribution enthalten ist. Stand „Heute“ wird das nicht der Fall sein 😉

Im Gegensatz zu manch anderem Tool, ist das kompilieren, eine einfache Sache:

gcc pathdiscover.c  -o pathdiscover

Das war es dann auch schon. Jetzt kann man das Programm z.b. nach /usr/bin/ verschieben und so allen Benutzern zur Verfügung stellen. Kann aber sein, daß es in einigen Monaten und Jahren, wenn sich die Systemumgebung geändert hat, man neu kompiliert werden muß.

Wann braucht man das Programm ?

Das Einsatzgebiet liegt hauptsächlich bei Admins, die sich z.b. fragen, wieso eine Datei von Serverdienst X nicht erreicht werden kann. Meistens sind da die Besitzerrechte der Ordner und Dateien im Weg, weil man z.b. vergessen hat, den Besitzer der Datei zu ändern oder globale Leserechte vergessen hat.

Mit dem Programm bekommt man alles auf einmal übersichtlich angezeigt, so daß es recht einfach wird, solche Probleme zu beheben. Man sieht auch gleich, ob Sym-LInks im Spiel sind, die z.b. von Proftp und Apache nicht immer akzeptiert werden. Kurzum, ein sehr praktischer Befehl.

Cinnamon – Das fehlende Icon

Problem:

Nach dem Update auf Fedora 26 zeigte die Schnellstartleiste ein leeres Iconfeld:

Schnellstartleiste ohne Icon

Schnell stellte sich heraus, daß es sich dabei um die NVIDIA-Settings handelte. Beim eingestellten ICON-Theme gnome :

Themeeinstellungen mit Gnome

 

gibt es nun aber gar kein Icon dafür, weswegen der Platz leer bleibt.

Alle Versuche, das durch direktes Zuweisen in der Desktop Datei unter /usr/share/applications  zubeheben, schlugen fehl.
Die Desktopdatei wurde immer wieder auf die Defaulteinstellungen „Icon=nvidia-settings“  zurückgesetzt.

Da wird wohl rohe Kraft nötig sein, um das System vom Gegenteil zu überzeugen! 😀

Die Lösung

Das läßt sich schnell beheben, wenn man einen Theme hat, so wie MINT-Y, der ein Icon dafür bereitstellt :

cp /usr/share/icons/Mint-Y/apps/256/nvidia-* /usr/share/icons/gnome/256×256/apps/

Dann noch schnell das Theme Cache erstellen :

gtk-update-icon-cache –force /usr/share/icons/gnome/

Ab sofort ist da wieder ein Icon, wo es hingehört. Dies muß man als Rootuser machen :

Iconleiste mit Icon drin