Ich habe auf einem System, das ich von Opensuse 12.1 auf Opensuse 12.2 upgegraded hatte, zweimal kurz hintereinander Probleme mit der Konsistenz des Root-Filesystems unter “ext4” bekommen.
Diese Schwierigkeiten kamen nach einigen größeren Update-Läufen, die ich nach dem Upgrade durchgeführt hatte.
Das Workstation-System beinhaltet einen LSI/3ware-Raid-Controller 9650SE mit einem Raid 10 Array. Das System hat sowohl unter Opensuse 11.4 als auch unter Opensuse 12.1 im Dauereinsatz gut und sehr performant funktioniert. Unter Opensuse 12.2 dagegen bereitet es nun leider Probleme nach Shutdowns mit PowerOff – die führen nämlich mindestens bei einer performance-orientierten Einstellung des Controllers zu Datenverlust und resultierenden Filesystem-Inkonsistenzen.
Interessanterweise konnte ich ähnliche Inkonsistenzen des Root-Filesystems trotz mehrer Anläufe und unterschiedlicher Einstellungen des Controllers nicht unter den auf dem PC immer noch vorhandenen Versionen Opensuse 11.4 und 12.1 provozieren. Das schließt RAM-Defekte praktisch aus. Man könnte nun noch auf einen Platten-Defekt in Sektoren, die die Root-Partition des Opensuse 12.2-Systems betreffen, als eigentliche Ursache tippen. Aber auch smartd zeigte keine Auffälligkeiten.
Die eine Frage ist also, wieso diese Probleme auf ein und demselben System hauptsächlich unter Opensuse 12.2 (vor allem nach umfangreichen SW-Updates) auftreten und nicht unter Opensuse 11.4 oder Opensuse 12.1.
Die andere Frage – und diese ist die für diesen Beitrag interessantere – ist, wie eigentlich systemd beim Booten mit einem inkonsistenten, korrumpierten Root-Filesystem umgeht.
Man muss sich ja selten genug mit dieser Situation auseinandersetzen – und fast hätte ich gerade wegen systemd nicht einmal gemerkt, dass ein gravierendes Problem vorlag ….
Früheres Verhalten von Opensuse bei defekten Root-Filesystemen unter System V
Man erinnere sich:
Unter System V stoppte der Bootprozess, wenn Opensuse 11.4 beispielsweise einen inkonsistenten Zustand des Filesystems entdeckte und wenn das dann automatisch gestartete “fsck” den Schaden nicht automatisch beheben wollte oder konnte. Der Admin wusste dann Bescheid, das System befand sich im Systemverwaltungs-Modus (Runlevel 1) und man konnte sich sofort um das Filesystem kümmern.
Das hatte u.a. den Vorteil, dass sich der Filesystem-Schaden in den vorgefundenen Grenzen hielt und nicht weiter durch Benutzung des fehlerhaften und inkonsistenten Systems verschlimmert wurde.
Aktuelles Verhalten von Opensuse 12.2 mit Systemd bei defekten Root-Filesystemen
Unter Opensuse 12.2 mit systemd ist die oben beschriebene, kluge Politik leider nicht mehr gegeben:
“fsck” (genauer e2fsck) wird zwar gestartet. Aber kommt “fsck” mit der Anzahl oder Qualität nicht klar, wird das fehlerhafte Root-Filesystem durch “systemd” nach kurzem Einblenden einer Warnung in die laufenden Startmeldungen gnadenlos gemounted und der Systemd-Bootvorgang setzt sich fort ! Ja – man mag es kaum glauben – mit einem korrumpierten Filesystem !
Das fand und finde ich nicht nur schockierend, sondern geradezu fahrlässig!
Denn man merkt das Ganze ggf. nur zufällig – nicht zuletzt wegen der hohen Geschwindigkeit von systemd. Bei angeschaltetem Plymouth sieht man u.U. gar nichts, wenn man nicht aufpasst. Zwar wechselt der Schirm beim Start von fsck zu einer Konsole mit Textmodus, aber danach geht es zügig weiter und man landet nach wenigen Sekunden im grafischen Modus – als ob nichts wäre.
Bei textorientiertem Startup ist es fast noch schwerer, das Problem mitzubekommen – die “fsck”-Warnung geht in
der Flut der schnell ablaufenden “systemd”-Meldungen zum Systemstart unter. Was für ein Sch….
Aber der Reihe nach!
Wann traten die Probleme auf?
Die Probleme traten bislang ausnahmslos nach umfangreichen mit YaST2 durchgeführten SW-Updates (KDE, Kernel, … ) auf. Und zwar dann, wenn ich nach den Updates nicht sofort einen Systemneustart durchgeführt hatte, sondern mehrere Stunden weiterarbeitete und danach einen Shutdown mit PowerOff machte.
Auf einem ähnlichen System, auf dem OS 12.2 neu installiert wurde, traten solche Probleme bislang nicht auf. Auch ein anderes upgegradetes System zeigt das Verhalten (noch) nicht. Die anderen Systeme befinden sich jedoch noch auf einem anderen SW-Update-Level.
Allerdings weisen diese anderen Systeme bzgl. des Write-Caches des Raid-Controllers auch andere Einstellungen auf:
Der Parameter “StorSave” des 9650-Raid-Controllers steht im Fall der anderen Systemen auf “Balance” – im Fall der problematischen Systeme jedoch auf “Performance”.
Der Controller der problembehafteten Systeme ist ferner nicht batteriegepuffert. Vielleicht passieren im Rahmen des von systemd gesteuerten Shutdowns bei “performanter” Nutzung des Schreibcaches ja unangenehme Dinge. Vielleicht wird der Puffer des LSI/3ware-Controllers beim Shutdown nicht rechtzeitig geleert, vielleicht wird kein “sync” mehr aufgerufen – was weiß ich.
Man muss die Sache, die erst mit Opensuse 12.2 aufgetreten ist, jedenfalls beobachten:
Das Problem trat ausschließlich auf dem Root-Filesystem auf. Alle anderen gemounteten Filesysteme (alle vom Typ “ext4”) des gleichen Raid 10 Arrays – auch solche für virtuelle Maschinen – meldeten auch bei regelmäßig erzwungenen fsck-Vorgängen keinerlei Problem. Das ist deswegen interessant, weil das Root-Filesystem vor dem Power Off als letztes ausgehängt wird.
Ein Verify des Raid-Arrays zeigt nach einem Auftreten von Fehlern im Root-Filesystem jedenfalls auch aufgetretene Parity-Fehler an. Das spricht ein wenig dafür, dass der Shutdown unter “systemd” ggf. zu rasch erfolgt. Komisch nur, dass das auf dem gleichen System unter Opensuse 12.1 nicht geschieht ! Eine Problem zwischen Treiber und Kernel 3.4 ???
Ich habe den LSI/3ware-Controller nun einige Wochen im “Balanced” Modus des Schreibcaches betrieben. Es trat bis heute kein weiteres Problem mit dem Root-Filesystem auf.
Noch fehlt allerdings noch die Gegenprobe, um auszuschließen, dass das Problem nicht einfach durch problematische Update-Pakete oder Update-Vorgänge erzeugt wurde. Ich hatte dafür wegen anderer Themen bislang einfach keine Zeit.
Wegen der Raid-Controller-Einstellungen möchte ich das Ganze bislang also lediglich als Beobachtung ansehen, deren Ursache unklar ist. Ich werde den Raid-Controller nun wieder auf “Performance” stellen und die Sachlage weiter verfolgen.
Nachtrag 19.01.2013:
Nach vielen Tests muss ich leider feststellen: Bei einem Shutdown mit PowerOff kommt es unter OS 12.2 und systemd mit relativ hoher Wahrscheinlichkeit zu Datenverlusten und inkonsistentem Root-Filesystem, wenn der 3Ware-Controller bzgl. der Schreibpufferung (Parameter “Storsave”) auf “Performance” eingestellt ist.
Wie äußerte sich die Inkonsistenz des Root-Filesystems?
Falsche Inode-Verweise, vor allem etliche verwaiste Inodes und falsche Referenz-Counter. Interessant ist, dass die Dateien, die im Rahmen der letzten “fsck”-Bereinigung im Verzeichnis “lost&found” auftauchten, alle mit YaST2 selbst zu tun
hatten.
Die Schäden waren insgesamt jedenfalls von einer solchen Qualität, dass das automatisch gestartete “fsck” damit nicht mehr ohne User-Eingriffe klarkommen wollte. In den von mir beobachteten 2 Fällen tauchte deshalb der Hinweis auf ein manuell durchzuführendes “e2fsck” auf (s.u.) !
Was macht Systemd beim Starten mit Inkonsistenzen im Root-Filesystem ?
Tja, in meinen Fällen bemerkte systemd beim Starten zwar die Fehler im Filesystem.
fsck wurde dann gestartet. Aber in den Fällen, in denen fsck nicht mehr ohne Userunterstützung mit den Fehlern klarkommen wollte, wurde das kaputte Filesystem – wie gesagt – gnadenlos gemountet.
Dies geschah in meinem Fall an vier Tagen hintereinander (2.11. bis 5.11.), weil ich von den Fehlern – dank des “fantastisch” schnellen systemd – im Entwicklungsstress nichts mitbekommen habe. Erstaunlich, dass ich überhaupt arbeiten konnte.
Nachfolgend ein Auszug aus “/var/log/messages”:
Nov 2 08:49:25 mux kernel: [ 36.774057] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 2 08:49:25 mux kernel: [ 36.774270] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
Nov 2 08:53:58 mux kernel: [ 325.684513] EXT4-fs (sda6): error count: 1896
Nov 2 08:53:58 mux kernel: [ 325.684518] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 2 08:53:58 mux kernel: [ 325.684523] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
Nov 3 09:41:24 mux kernel: [ 30.059173] bootsplash: status on console 0 changed to on
Nov 3 09:41:24 mux kernel: [ 30.849236] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 3 09:41:24 mux kernel: [ 30.855514] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
Nov 3 09:46:00 mux kernel: [ 322.602348] EXT4-fs (sda6): error count: 1896
Nov 3 09:46:00 mux kernel: [ 322.602353] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 3 09:46:00 mux kernel: [ 322.602357] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
Nov 4 08:34:31 mux kernel: [ 34.497854] bootsplash: status on console 0 changed to on
Nov 4 08:34:31 mux kernel: [ 35.111163] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 4 08:34:31 mux kernel: [ 35.111397] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
Nov 4 08:39:07 mux kernel: [ 326.695619] EXT4-fs (sda6): error count: 1898
Nov 4 08:39:07 mux kernel: [ 326.695621] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 4 08:39:07 mux kernel: [ 326.695623] EXT4-fs (sda6): last error at 1352014560: ext4_lookup:1045: inode 922286
Nov 5 09:37:30 mux kernel: bootsplash: status on console 0 changed to on
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): error count: 2368
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): last error at 1352067644: ext4_lookup:1045: inode 922721
Hübsch, nicht? Seitdem lasse ich “/var/log/messages” nach jedem Bootvorgang auf entsprechende Schlüsselwörter scannen.
Systemd im aktuellen Zustand ist dem Admin jedenfalls nicht dabei behilflich, solche katastrophalen Entwicklungen mit korrumpierten Filesystemen zu vermeiden.
Aber: ich will mich ja nicht aufregen …..
Schadensbehebung – trotz Chaos mit dem Rescue Target
Nun versuche man mal, auf einem von “systemd” gesteuerten Opensuse-System, das Rescue-Target zu erreichen, um “fsck” – wie empfohlen – manuell ablaufen zu lassen. Ich habe das interessehalber auf verschiedenen Systemen in verschiedenem Upgrade-Zuständen getestet.
Ergebnis: Es war unter Opensuse 12.1 und zeitweise (!) auch unter Opensuse 12.2 (vor allem im Originalzustand) fast abenteuerlich, das “isolated rescue target” zu erreichen:
- Das lt. SuSE angeblich noch funktionierende “init 1” führte auf mehreren Systemen zu einem Herunterfahren des Systems mit unmittelbar danach – und ohne oder gar trotz Userinteraktion – ablaufendem Restart in das “default target” – also den grafischen Modus.
- “systemctl isolate rescue.target” zeigte – je nach Update-Zustand des Opensuse 12.1 oder 12.2-Systems das gleiche fehlerhafte Verhalten wie “init 1” oder aber ein unterschiedliches Verhalten – je nachdem, ob es von Konsole “tty2” oder “tty1” gestartet wurde.
- Zwischenzeitlich funktionierte dann lediglich “systemctl rescue” halbwegs wie erwartet. Einen Wechsel der Konsole musste man dabei aber vermeiden. Das Verhalten von systemd war in jedem Fall schwierig – oft verlor man auch den Prompt auf der Konsole, von der der Shutdown gestartet wurde. Überhaupt mutet es merkwürdig an, dass im “Rescue Modus” mehrere Konsolen ansprechbar sind.
- Ein mehrfaches Hintereinanderausführen des Herunterfahrens in den Rescue Modus mit anschließendem Hochfahren in den Default-Modus mit Konsol-Wechsel verhielt sich z.T. unberechenbar.
Wohlgemerkt: Ich spreche hier von Tests auf Systemen, die (außer systemd) keine Defekte beherbergen.
Inzwischen – also auf dem aktuellen Update-Niveau des Opensuse 12.2-Systems – haben sich die Dinge aber deutlich verbessert. Nun funktionieren
“systemctl isolate rescue.target”
und
“systemctl rescue”
im wesentlichen wie erwartet. Man habe Geduld – die Meldung zum Eingeben des Passwortes und der Prompt erscheinen manchmal zeitversetzt.
Bevor nun aber möglicherweise Ekstase bei den systemd-Anhängern aufkommt – es gibt immer noch gravierende Probleme mit der systemd-Logik:
- Ein anschließendes “systemctl default” führt zwar zum Hochfahren in den graphischen Modus – auf der ursprünglichen Konsole mag sich unter Opensuse 12.2 aber der Prompt nicht mehr einstellen.
- Ferner läuft der “agetty”-Prozess nach “systemctl rescue” und einem anschließenden “systemctl default” unter Opensuse 12.2 regelmäßig Amok und verbraucht 90% der CPU-Zeit eines Prozessor-Cores. Man muss “agetty” tatsächlich abschießen, um dem Herr zu werden.
So ist das halt, wenn ein einziges Super-Programm wie “systemd” alles und jedes im System unter Kontrolle behalten muss. Die Tatsache, dass es mit mehreren Konsolen umgehen muss, ist von der neuen Superlösung wohl noch nicht richtig verdaut worden.
Aber ich rege mich nicht auf ….. auch vor den letzten Systemupdates kam man (nach mehreren Konsole-Wechseln und unermüdlichem Probieren) meist doch irgendwie in einen Zustand, der dem früheren “init 1 ” irgendwie ähnelte.
Leider, leider hieß das aber noch lange nicht, dass dann unter “systemd” immer ein
“mount -o remount,ro /dev/rootdevice”
für einen manuellen fsck-Lauf möglich gewesen wäre.
Das ging nur in 50 % der von mir untersuchten Fälle. Bei den Systemen mit bereits vorhandenem Filesystem-Fehler gar nicht. Vielleicht auch bedingt durch die sich inzwischen vergrößerten Probleme mit dem inkonsistenten Filesystem.
Ich musste
jedenfalls in zwei Fällen auf eine CD mit “Rescue-System” ausweichen und von dort meine Root-Partition auf der Platte reparieren.
Seitdem habe ich wieder Ruhe. Was immer die Ursache des defekten Filesystems war – der eigentliche Skandal ist der Umgang von systemd mit einem defekten Filesystem beim Booten !