Author Archives: marius

Wenn Cinnamon ständig crashed

Posted on by

Warum immer in der Weihnachtszeit ? Die sollte doch so friedlich sein. Mein Laptop war anderer Meinung. Vor zwei Wochen erst auf Fedora 26 aktualisiert und seit Mittwoch crasht Cinnamon in Endlosschleife in seinen Rückfallmodus, ohne irgendeine brauchbare Spur zu hinterlassen. Na gut, Challenge Accepted!

Die Versuchsreihe

Zunächst mal sollte man checken, ob man vielleicht ein neues Update bekommen hat und dies das Problem löst. Tat es nicht, weil keines kam.

Ok, jetzt müßte man doch mal nachsehen, was da unter der Haube los ist. Also „journalctl -xe | grep -i cinnamon“ eingegeben und … nichts.

Ok, versuchen wir es ohne den Filter : „journalctl -xe“ und siehe da, jede Menge rote Crashmeldungen in diversen Libs, aber leider kein Hinweis, was da der Auslöser sein könnte. Auch 1 Stunde später, und diverse andere Logs und Webseiten später, senkte sich vom Baum der Erkenntnis die rote Kartenfrucht herab.

Der Reinstall

Ein klares Signal, einen Reinstall durchzuführen, also als Root eingegeben:

dnf reinstall „cinnamon*“

Und wieder in Cinnamon einloggen… args.. gleiches Ergebnis. Hmm.. da hat es wohl noch mehr zerlegt… uff. Also, ‚ dnf reinstall „*“ ‚ eingegeben, also die ersten 80 Pakete bereits runter geladen waren, wollte ich aber doch noch mal etwas anderes austesten.

adduser -s /bin/bash testuser
passwd testuser

Und dann mal als Testuser einloggen. Oh… Das geht ja … Da ist dann wohl doch nur die Session defekt. Dann hauen wir die halt weg:

rm -rf ./.config/cinnamon-session ./.local/share/cinnamon ./.cinnamon

Danach ist der Account so jungfräulich, daß Cinnamon alles wieder sauber anlegt und oh Wunder, dann geht es auch wieder mit dem Login 😀

Man muß natürlich alles neu einstellen,aber das ist ein kleiner Preis. Was meine Session/Einstellungsdaten genau getroffen hatte, wird man wohl nie erfahren 😉

 

Systemd : The Revenge of Mariadb III

Posted on by

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

Posted on by

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.