Fehler bei Kernel-Upgrade auf 6.1.64-1: „broken package“

[cosinus]

Auch hier gilt, was nicht von eine Datenbank geschrieben wurde, ist mit fast 100%iger Sicherheit in Ordnung.

Führt denn automatisch ein O_DIRECT zum Datensalat? Ich kann hier nämlich immer noch keine Fehler feststellen.

[MSfree]

Führt denn automatisch ein O_DIRECT zum Datensalat? Ich kann hier nämlich immer noch keine Fehler feststellen.

Ja.

Das läuft ungefähr so ab:

Code: Alles auswählen

positioniere Datei an Stelle 12345 mit fseek()
schreibe 234 Bytes
schreibe weitere 123 Bytes

-> Datei kaputt

Grund:
Nachdem die ersten 234 Bytes geschrieben wurde, sollte der Dateipointer von 12345 auf 12345-234=12579 "vorgespult" werden, er bleibt bei O_DIREKT aber wegen des Kernelbugs bei 12345 stehen, weil er nicht aktualisiert wird. Die nächsten 123 Bytes überschreiben also die ersten 123 Bytes der zuvor geschriebenen 234 Bytes.

Wenn allerdings jeder Schreiboperation ein fseek() vorausgeht, passiert kein Datensalat.
Wenn keine Schreiboperationen stattfinden, also nur gelesen wird, passiert ebenfalls kein Datensalat.

Bei gepufferten und gecachten Dateioperationen (also bei Nichtverwendung von O_DIRECT) funktioniert der kaputte Kernel jedoch korrekt, und das stellt die absolute Mehrheit der Anwendungssoftware dar.

O_DIREKT ist nämlich eine starke Performancebremse. Es gibt nur ganz wenige Ausnahmen, bei denen O_DIREKT sinnvoll einsetzbar ist, nämlich dann, wenn ein Programm mit exakt der Blockgröße des Dateisystems liest/schreibt und sich selbst ums Puffern und Cachen kümmert. Den Aufwand, selbst das Dateisystem zu Puffern und Cachen, betreibt man in kaum einer Software, ausser einigen wenigen Datenbankprogrammen.

[slu]

Das wird alles noch spannend, wir haben hier zwei Systeme die eine MariaDB einsetzten, da wurde aber nichts oder nur sehr wenig gemacht.
Beides keine System kritischen Systeme, bin mal gespannt ob das irgendwann wieder hoch kommt.

Vielleicht machen die auch das fseek() wie von MSfree beschrieben, wer weiß.

[MSfree]

Das wird alles noch spannend, wir haben hier zwei Systeme die eine MariaDB einsetzten, da wurde aber nichts oder nur sehr wenig gemacht.

Wenn du häufige Sicherungen mit mysqldump erstellst, kannst du eine kaputte Datenbank ja neu aufsetzen. Mein Mediawiki wird täglich gedumpt, verlieren würde ich hier also höchstens einen Tag. Da mein Mediawiki mit MariaDB nur mir als Notizblock dient, bei dem sich weit weniger als täglich etwas ändert, wäre ich auch hier auf der sicheren Seite.

Vielleicht machen die auch das fseek() wie von MSfree beschrieben, wer weiß.

Der Sourcecode ist öffentlich, schau halt selbst nach.
OK, das war zynisch, ich wüßte jetzt auch nicht, wo ich da mit suchen anfangen sollte.

[cosinus]

Ok. Ich geht hier gerade mit dem von @Livingston vorgeschlagenen strace auf den Prozess von mariab los und lasse das loggen. Mal sehen ob ich da nen O_DIRECT finde.

[MSfree]

Ok. Ich geht hier gerade mit dem von @Livingston vorgeschlagenen strace auf den Prozess von mariab los und lasse das loggen. Mal sehen ob ich da nen O_DIRECT finde.

Ich hatte $SUCHMASCHINE mit O_DIRECT ud MariaDB gefüttert. Die verwendet das wohl, allerdings habe ich hier auch den Hinweis gefunden, daß das in der Enterpriseversion genutzt wird. Dennoch bin ich auf das Resultat deines Traces gespannt.

[4A4B]

Bei Verwendung der Innodb Engine ist die Variable innodb_flush_method ggf. aufschlussreich:

Code: Alles auswählen

MariaDB [(none)]> show variables like 'innodb_flush_method';
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| innodb_flush_method | O_DIRECT |
+---------------------+----------+
1 row in set (0.001 sec)

[slu]

Ja das steht hier auch:
https://mariadb.com/kb/en/innodb-system-variables/

Ich hab jetzt 53MB strace (mit -f) und noch kein O_DIRECT gefunden, ich lass es weiter laufen.
Mein KVM Gast hat auch kein O_DIRECT erzeugt, sind aber erst 22MB, lass ich auch weiter laufen.

[cosinus]

Dennoch bin ich auf das Resultat deines Traces gespannt.

Seit etwa einer Stunde zeichnet strace nun alles auf was der Prozess mariadb macht. Auf meinem Inventory-Server wurden da seitdem nur ca. 116 kiB ins Log geschrieben...find ich etwas wenig aber soviel los ist da auch nicht. Alle paar Minuten melden sich die Clients mit ihren Agents und melden ihren neuen Status per HTTP...ein O_DIRECT sehe ich da nicht im Log aber viele Einträge wie

Code: Alles auswählen

accept4(25, ...)
clone3({flags=CLONE_VM|CLONE_FS ...
poll([{fd=23, events=POLLIN}
rt_sigprocmask(SIG_BLOCK, ~[], [HUP INT QUIT PIPE ALRM TERM TSTP], 8) = 0
futex(0x561b0d7447ac, FUTEX_WAKE_PRIVATE, 1) = 1

Sollte ich vllt mal apache2 loggen? Oder macht der kein O_DIRECT?

edit: ich hab das -f bei strace vergessen also nochmal.

[slu]

Sollte ich vllt mal apache2 loggen? Oder macht der kein O_DIRECT?

Schaden kann es nicht, wobei der Webserver ja in der Regel nicht so viel wegschreiben (sollte).

edit: ich hab das -f bei strace vergessen also nochmal.

Ist mir beim ersten mal auch passiert, war verdächtig ruhig.

[MSfree]

Sollte ich vllt mal apache2 loggen? Oder macht der kein O_DIRECT?

Apache schreibt eigentlich nur seine Logs und die mit ziemlicher Sicherheit nicht mit O_DIRECT.

OK, man kann mit mit PHP natürlich auch Dateien auf den Server schreiben, z.B. in Form eines Uploads. Aber auch hier würde ich keine Schreibvorgänge mit O_DIRECT erwarten.

[cosinus]

Ich hab jetzt einen ersten Treffer. Aber nicht bei OCS sondern bei einer anderen VM wo noch ein OTRS-Ticketsystem mit mariadb läuft, was aber de facto nicht mehr genutzt wird. Hab da testweise Tickets gelesen und eine Notiz bei einem zum Testen hinterlassen, bei was genau das O_DIRECT ausgelöst wurde weiß ich aber nicht.

Code: Alles auswählen

fcntl(193, F_SETFL, O_RDONLY|O_DIRECT) = 0

Seh ich das richtig? Das war nur ein readonly Öffnen?

Hab nochmal ein Testticket erstellt...aufgezeichnet von strace wurde das hier:

Code: Alles auswählen

# grep -in o_direct mariadb.strace 
23502:33284 fcntl(196, F_SETFL, O_RDONLY|O_DIRECT) = 0
24129:33284 fcntl(197, F_SETFL, O_RDONLY|O_DIRECT) = 0

[JTH]

Code: Alles auswählen

fcntl(193, F_SETFL, O_RDONLY|O_DIRECT) = 0

Seh ich das richtig? Das war nur ein readonly Öffnen?

Ja. Solange die so direkt-gelesenen Daten nicht wieder an anderer Stelle zurückgeschrieben werden, wäre das wohl rein auf Dateiebene ungefährlich.

Ob die lesende Anwendung durch eine gelesene und womöglich kaputte Datei (unerkannt) Mist baut, wäre aber eine Frage auf ner Ebene über dem reinen Dateizugriff.

[cosinus]

Ok. Dann schauen wir mal was mariadb auf unserem Nextcloud-Server so treibt. Logging mit strace gestartet, mit Parameter f
Dann in nextcloud per Browser eingelogt und ne Datei hochgeladen.
grep findet kein O_DIRECT

Ich lass das noch etwas laufen und grepe dann nochmal. Das strace.log hat jetzt gute 4 MB nach 2 Minuten.

[slu]

Ok. Dann schauen wir mal was mariadb auf unserem Nextcloud-Server so treibt. Logging mit strace gestartet, mit Parameter f

Mein Log läuft jetzt seit über einer Stunde 129 MB auf dem Nextcloud Server:

Code: Alles auswählen

grep "O_DIRECT" nextcloud_mariadb.log 
11880 openat(AT_FDCWD, "./nextcloud/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 203
11903 openat(AT_FDCWD, "./nextcloud/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 203
11905 openat(AT_FDCWD, "./", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 203

Datenbank Dump ist auch gelaufen, bisher noch nichts auffälliges.

[MSfree]

Code: Alles auswählen

11880 openat(AT_FDCWD, "./nextcloud/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 203
11903 openat(AT_FDCWD, "./nextcloud/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 203
11905 openat(AT_FDCWD, "./", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 203

O_DIRECTORY ist etwas völlig anderes und hat mit O_DIRECT nichts zu tun, zumal das ohnehin alles Read-Only Operationen sind.

Mit O_DIRECTORY kann man Unterverzeichnisse wie eine Datei öffnen.
Mit O_DIRECT werden Daten roh ohne Umweg über Puffer und Cache gelesen und geschrieben.

[slu]

O_DIRECTORY ist etwas völlig anderes und hat mit O_DIRECT nichts zu tun, zumal das ohnehin alles Read-Only Operationen sind.

Das ist klar, sorry ich wollte damit sagen Strace sammelt Daten und ich habe den grep richtig gschrieben.

[cosinus]

Das ist klar, sorry ich wollte damit sagen Strace sammelt Daten und ich habe den grep richtig gschrieben.

Also ich gehe mittlerweile davon aus, dass kein Schaden entstand in der kurzen Zeit in der bei uns der broken kernel lief. Alle Systeme laufen auch völlig normal.
Eine VM mit mariadb schau ich mir noch an, dann werde ich das Thema abhaken.

[Livingston]

Code: Alles auswählen

fcntl(193, F_SETFL, O_RDONLY|O_DIRECT) = 0

O_DIRECT kann bei O_RDONLY nicht zuschlagen. Da geht nix auf die Platte.

[cosinus]

O_DIRECT kann bei O_RDONLY nicht zuschlagen. Da geht nix auf die Platte.

Genau, das O_RDONLY hab ich auch so interpretiert. Weitere O_DIRECT hab ich bisher nicht gesehen. Auch keine mit O_RDONLY. Würde erklären warum die Server alle problemlos laufen. Nicht weil mi keine Fehler auffilen, sondern weil O_DIRECT garnicht passiert!

Mal gut, dass ich nicht wie ein aufgescheuchtes Hühnchen am Sonntag alles geplättet hab.

[Livingston]

Wichtig bei strace: Man sollte mitbekommen, was beim Öffnen von Dateien passiert. Wenn man sich mit der Option -p <PID> in einen bereits laufenden Prozess einklinkt, bekommt man das möglicherweise nicht mit. Ebenso können bereits Kindprozesse abgespalten sein, die man dann auch mit -f nicht mehr erwischen kann. Im letzteren Fall muss man also mit pstree nachforschen, was vom Hauptprozess aus gestartet wurde und darauf gesondert ein strace absetzen.

EDIT: Sehr vernünftig, Monsieur Cosinus

[HumiNi]

Ich finde es erstaunlich, dass so ein gravierender Bug erst bei Auslieferung auf stable bemerkt wird. Irgendwie kratzt das an meinem Verständnis der Debian-Philosophie.
Auch als Nur-noch-User will ich eins garantiert nicht haben: versteckte Daten-Beschädigungen, die ich erst bemerke, wenn die validen Backup-Versionen nicht mehr existieren.

[slu]

Irgendwie kratzt das an meinem Verständnis der Debian-Philosophie.

Einfach mal etwas im Internet suchen, da wird beschrieben wie es zu dem Problem kommen konnte.
Mit Debian hat das erst mal nichts zu tun, das war halt Pech.

[Livingston]

Ich finde es erstaunlich, dass so ein gravierender Bug erst bei Auslieferung auf stable bemerkt wird.

Ein tragischer Unfall, wie er alle 20 Jahre einmal vorkommt.
Nicht vergessen, dass hier Debian wenig Schuld dran trägt. Bei den Profis von kernel.org ist das Kind schon in den Brunnen gefallen, und das kommt bei denen gerade in solch kritischen Bereichen nur allerseltenst vor.
Außerdem hat das Krisenmanagement bei Debian sehr gut gegriffen.

[TRex]

Daten-Beschädigungen, die ich erst bemerke, wenn die validen Backup-Versionen nicht mehr existieren.

Ohne auf dir rumhacken zu wollen: dein Backup sollte im Optimalfall dagegen resilient sein, wenn es das Risiko nicht tragen soll. In dem Fall ists meins auch nicht, weil ich das zu sichernde System selbst auf das Dateisystem zugreifen lasse, wie vermutlich die meisten hier. Ist halt wie immer ne Abwägung, gegen welche Probleme du geschützt sein willst. Ich hab auch kein offsite-Backup. Ich verliere aber weder Geld noch hängt irgendwas größeres (Firma, Ehe, ...) an den Daten, sodass ich mich nicht gegen Erdbeben und Meteoriten absichere.