Die­ses Blog hat in den ver­gan­ge­nen zwei Tagen mas­si­ve Aus­fäl­le gehabt. Von Diens­tag vor­mit­tag bis Mitt­woch nach­mit­tag war der Rech­ner nur spo­ra­disch online. Und nicht nur die­ser Rech­ner, son­dern alle vir­tu­el­len und die phy­si­ka­li­sche Maschi­ne mei­nes Ser­vers. Und das kam so:

Ser­ver von innen: Nur kei­ne Panik

Am Diens­tag mor­gen hat die auto­ma­ti­sche Update-Rou­ti­ne mei­ner Ubuntu-18.04-Server mal wie­der neue Updates instal­liert. Ich habe das grund­sätz­lich auf allen Rech­nern ein­ge­schal­tet und im Voll­au­to­ma­tik-Betrieb: Instal­lie­re und wenn nötig, reboo­te. Die­se Reboots fin­den dann auf Grund von Zusam­men­hän­gen, die ich bis heu­te nicht voll­stän­dig durch­drun­gen habe, erst am dar­auf­fol­gen­den Mor­gen statt.

Nun habe ich aber an die­sem Mor­gen bereits am Rech­ner geses­sen und als ich das gese­hen habe, dach­te ich mir: „Ok, ich löse den Reboot jetzt ein­fach hän­disch aus, dann haben wir es hin­ter uns.” Aber ach!

Nach dem Reboot beginnt dann das Cha­os. Rech­ner da – Rech­ner weg. Ich bekom­me die E‑Mail vom Moni­to­ring-Sys­tem. Ein­log­gen nicht mög­lich. Hard­ware-Reset auf der Hetz­ner-Kon­so­le. Rech­ner da. Puh. Rech­ner wie­der weg. Mist. Hard­ware-Reset auf der Hetz­ner-Kon­so­le. Rech­ner da. Hm. Rech­ner wie­der weg. Riesen-Mist.

E‑Mail an Hetz­ner: „Was ist da los?” Ant­wort: „Da ist eine Ker­nel Panic. Wir haben eine Remo­te-Kon­so­le ange­schlos­sen.” Ich mache also etwas, das ich bis­her stets ver­mie­den habe: Ich schaue mei­nem Miet­ser­ver auf die Konsole.

Die ist kom­plett voll­ge­schrie­ben mit einer Ker­nel Panic des Linux-Ker­nels. Das hat­te ich so auch noch nicht. Die Ker­nel Panic und ich schau­en uns eine Wei­le gegen­sei­tig an. Schließ­lich löse ich einen Reset des Rech­ners aus. Genau so wie die bei­den vori­gen Male, bloß dass ich dies­mal zuschau­en kann.

Die Kis­te boo­tet… Fährt hoch… Kon­so­le… Vir­tu­el­le Maschi­nen… Ist da… Rrrrr­rums! Ker­nel Panic. Noch ein Anlauf (man glaubt das ja erst­mal gar nicht). Das­sel­be Spielchen.

Ich gehe ins BIOS. Und traue mei­nen Augen kaum: Die­ser kreuz­bra­ve, mit Enter­pri­se-Fest­plat­ten aus­ge­stat­te­te Ser­ver-Oldie aus der Gebraucht-Bör­se ist mit Hil­fe des „Over­clo­cking-Wizards” im Intel-BIOS auf „1,25-faches Over­clo­cking” ein­ge­stellt! Ich fas­se es nicht! Umge­hend been­de ich die­sen Spuk und den­ke mir: „Hof­fent­lich hat die Hard­ware nichts abge­kriegt.” Der Rech­ner hat­te vor eini­gen Mona­ten mas­si­ve ther­mi­sche Pro­ble­me, die erst im zwei­ten Anlauf mit neu­en Lüf­tern voll­stän­dig besei­tigt waren. Ich begin­ne zu ahnen, was da das eigent­li­che Pro­blem war…

Neu­er Anlauf ohne Over­clo­cking. Geht. Geht? Geht??? Nein, Crash. BIOS. Ich fol­ge der Ver­mu­tung „Hard­ware­pro­blem durch ther­mi­sche Alte­rung” und schal­te das Hyper­th­re­a­ding des Core-i7-3000-Pro­zes­sors aus. Außer­dem fah­re ich unmit­tel­bar nach dem Reboot alle vir­tu­el­len Maschi­nen wie­der run­ter und deak­ti­vie­re das auto­ma­ti­sche Hochfahren.

Jetzt stellt sich eine gewis­se Sta­bi­li­tät ein. Der Rech­ner läuft. Ohne die vir­tu­el­len Maschi­nen macht er aber nichts wirk­lich Hilf­rei­ches. Nach zehn Minu­ten schal­te ich den ers­ten der vier vir­tu­el­len Rech­ner wie­der ein. Dann den zwei­ten. Num­mer drei. Na? Ok, Num­mer vier. Auf all den vir­tu­el­len Maschi­nen füh­re ich nach dem Reboot erst­mal etwas grö­ße­re Netz­werk­ope­ra­tio­nen aus – läuft alles durch.

Es ist Mit­tag. Ich gehe essen. Wäh­rend ich unter­wegs bin, kommt wie­der eine Alarm­mel­dung aufs Han­dy: Ser­ver down.

Ich schil­de­re die Vor­fäl­le in einer län­ge­ren E‑Mail dem Hetz­ner-Sup­port und äuße­re dabei die Ver­mu­tung, dass die sowie­so schon ange­grif­fe­ne Hard­ware durch den Reboot am Mor­gen und die nach­fol­gen­de Hoch­last­pha­se bei Reinitia­li­sie­ren der gan­zen vir­tu­el­len Rech­ner und deren Ser­vices final einen weg bekom­men hat und nicht mehr zuver­läs­sig läuft.

Hetz­ner reagiert prompt – und tauscht den gan­zen Rech­ner aus. Ich bin etwas per­plex, aber der Erfolg scheint ihnen erst­mal Recht zu geben: Der Rech­ner fährt sta­bil hoch und funk­tio­niert. Ich bin glück­lich. Vor lau­ter Freu­de über­se­he ich aber ein läs­ti­ges Detail: Die neue Hard­ware hat eine neue MAC-Adres­se. Die vir­tu­el­le Bridge arbei­tet aber noch mit der alten Adres­se, die auch „nach drau­ßen” über­mit­telt wird. Und dadurch kom­men kei­ne IPv4-Pake­te mehr an. Der Rech­ner ist recht weit­räu­mig vom Inter­net abgeschnitten.

Bemerkt wird das – mal wie­der – von den Über­wa­chungs­rou­ti­nen. Wäh­rend die gan­zen Checks auf IPv6-Basis nach und nach Ent­war­nung geben, kommt drei Stun­den nach der letz­ten War­nung eine neue: „IPv4 immer noch nicht erreichbar”.

Ich set­ze mich also am Abend hin und kon­fi­gu­rie­re das Netz­werk auf die neue MAC-Adres­se. Damit ändert sich auch die IPv6-Adres­se des phy­si­ka­li­schen Hosts, SLAAC sei Dank. Nach dem Reboot ist die IPv4-Konn­tek­ti­vi­tät wie­der da…

…und lei­der auch die Sta­bi­li­täts­pro­ble­me. Wäh­rend ich noch die letz­te vir­tu­el­le Maschi­ne hoch­fah­re, sehe ich aus Augen­win­keln auf der mitt­ler­wei­le wie­der ange­schlos­se­nen KVM-Kon­so­le… eine Kernel-Panic.

Das ist der Moment, in dem es mir zu bunt wird. Ich schrei­be Hetz­ner, die neue Hard­ware wür­de auch rum­spin­nen. Sie sol­len einen kom­plet­ten Hard­ware­check lau­fen las­sen. Dann gehe ich ins Bett, mitt­ler­wei­le ist es tief in der Nacht.

Mor­gens den­ke ich nach: Ich habe die gan­ze Zeit die Hard­ware in Ver­dacht. Der auf­fäl­ligs­te zeit­li­che Zusam­men­hang ist aber, dass die Pro­ble­me unmit­tel­bar nach dem Reboot nach den letz­ten Updates ange­fan­gen haben. Und was sagt Ock­hams Rasier­mes­ser? Es ist immer die ein­fachs­te Erklä­rung die richtige.

Was war denn eigent­lich in die­sem Update? Oh, ein neu­er Ker­nel. Das ist irgend­wie genau die Sys­tem­kom­po­nen­te, die seit­her mit Panics unan­ge­nehm auf­fällt. Ein Schelm, wer Böses dabei denkt.

Mitt­ler­wei­le ist es Mitt­woch mit­tag. Die Ergeb­nis­se des Hard­ware­tests sind da: Alles ok. Es wär’ ja auch zu schön gewesen…

Eine Beob­ach­tung war ja, dass der Rech­ner ohne die vir­tu­el­len Maschi­nen wesent­lich sta­bi­ler, even­tu­ell sogar voll­stän­dig sta­bil, läuft. Ich fah­re schnell die vir­tu­el­len Maschi­nen wie­der run­ter und baue die Kon­fi­gu­ra­ti­on des Boot­loa­der Grub so um, dass nicht der ges­tern instal­lier­te neue Ker­nel 4.15.0 – 60 gela­den wird, son­dern der älte­re 4.15.0 – 58.

Nach­dem die­ser Ker­nel auf der phy­si­ka­li­schen Maschi­ne läuft, fan­ge ich an, die vir­tu­el­len Rech­ner wie­der hoch­zu­fah­ren. Und sie­he da: Jetzt ist das Sys­tem wie­der sta­bil! Kei­ne Abstür­ze, kei­ne Panics – alles ist so, wie es sein soll. Mit apt-get mark manual sor­ge ich dafür, dass der 58er-Ker­nel kei­nes­falls durch auto­ma­ti­sche Updates ent­fernt wer­den wird. Und dann sehe ich mei­nem Rech­ner dabei zu, wie er ein­fach funktioniert.

Naja, und dann Mitt­woch am spä­ten Nach­mit­tag fin­de ich die Erklä­rung für das alles: Im Ubun­tu-Bug­tra­cker fin­det sich ein Bug­re­port, der genau mein Pro­blem beschreibt: Ker­nel Panic im Netz­werk­code und immer im Zusam­men­hang mit Docker-Instan­zen. Nun habe ich kein Docker, son­dern arbei­te mit „ech­ten” vir­tu­el­len Ser­vern, aber dabei ver­wen­de ich genau wie Docker ein gebrid­getes Netzwerk.

Lang­sam wer­den mir die Zusam­men­hän­ge klar: Der Bug wur­de Diens­tag mor­gen aktiv, nach­dem ich den 60er-Ker­nel geboo­tet hat­te. Inner­halb weni­ger Minu­ten Total­ab­sturz mit Ker­nel Panic – nicht gut. Immer wenn die vir­tu­el­len Maschi­nen abge­schal­tet waren, lief der Rech­ner pro­blem­los. Aber nicht etwa – wie von mir ver­mu­tet -, weil der Haupt­pro­zes­sor dann eine ruhi­ge Kugel schiebt, son­dern weil der Bug im IPv4-Code nicht getrig­gert wird.

Nach dem Hard­ware­tausch am Diens­tag mit­tag herrsch­te dann trü­ge­ri­sche Ruhe, weil eben genau die IPv4-Netz­werk­ver­bin­dun­gen inak­tiv waren; offen­sicht­lich gilt: Wo kei­ne Pake­te, da kein Absturz. In dem Moment, in dem ich das repa­riert hat­te und IPv4 wie­der ging, kamen auch sofort die Pro­ble­me zurück.

Mitt­ler­wei­le ist Mitt­woch Nacht. Der Rech­ner läuft, das Pro­blem ist gelöst. Sei­ne Ursa­che ist ver­stan­den und bei Ubun­tu arbei­ten sie gera­de an einem Bug­fix. Ich muss noch­mal an Ock­ham den­ken: Wenn ich am Diens­tag vor­mit­tag ein­mal in Ruhe über die Abfol­ge der Ereig­nis­se nach­ge­dacht hät­te, wäre ich viel­leicht von selbst drauf gekom­men, dass vor der Hard­ware der Ver­dacht erst­mal auf die frisch instal­lier­te Soft­ware hät­te fal­len müs­sen. Es ist so viel nahe­lie­gen­der, dass ein Update schlicht ein kaput­tes Pro­gramm auf­spielt, als dass durch den Update­pro­zess irgend­wel­che obsku­ren unter­stell­ten Hard­ware­pro­ble­me auftreten.

Nun ist der Rech­ner jeden­falls wie­der da. Und ich kann wie­der ruhig schla­fen. Am Ende war das Sze­na­rio voll­stän­dig ver­stan­den und hat sich gar nicht als so unend­lich schwie­rig zu meis­tern her­aus­ge­stellt. Ich hät­te aber auch gern drauf verzichtet.

Nach­trag, 2019-09-10: Mitt­ler­wei­le gibt es einen aktua­li­sier­ten Ker­nel 4.15.0 – 62, der wie­der pro­blem­los läuft.