Browsed by
Month: June 2016

Soft Lockup yourself!

Soft Lockup yourself!

Ich rege mich gerade schon wieder viel zu sehr auf. Worüber? Developer natürlich! Warum? Developer natürlich!

Die aktuelle Lieblings-Spielwiese meiner Devs ist ja nun, wie es sich für mode- und trendbewusste Nerds gehört, Docker. Warum man neuerdings unbedingt alles in Container packen muss, wofür auch ein Paket gereicht hätte, erklär mir mal bitte einer, der seine Seele noch nicht in einer cgroup weggesperrt hat.

Jedenfalls gab es bei Lasttests auf einem kleineren Cluster lustige CPU Soft Lockups, die – wie es “zufällige” Verteilung auf Computern nunmal so will – erstmal immer auf derselben Kiste auftraten. Der zuständige Entwickler, nennen wir ihn an dieser Stelle einfach mal Sylvester, schlussfolgerte sofort: Die böse Hardware ist schuld. Wenn Entwickler etwas nicht verstehen ist schließlich immer die Hardware schuld. Oder ich. Da ist mir die Hardware dann doch lieber. Dass ich dann mehrfach versucht habe zu erklären, dass Soft Lockups eigentlich aufgrund ihrer Struktur quasi kein Hardwarefehler sein können, war ihnen ziemlich egal. Glücklicherweise gibt es bei uns einen Developer, nennen wir ihn mal Ewok, der schon auf unterschiedlichen Systemebenen gearbeitet hat und mir beipflichtete. Sollte er das hier jemals lesen, danke dafür. Ich schlug ein Kernel-Update vor, da das laut vergangener Docker-Bugs mit ähnlichen Symptomen wohl schon öfter geholfen hat. Aber wer hört schon der kleinen Blondine aus dem Admin-Büro zu.

Leider war die Anzahl der Ausfälle auf der betreffenden Kiste (3) statistisch signifikanter als die Menge der Menschen, die sagten, dass ein Hardwarefehler extrem unwahrscheinlich sei (2), woraufhin ich einen Memtest beim Hoster beantragte. Nachdem das soweit ergebnislos verlief kam es, wie es kommen musste:

Heute morgen hatte ich ein Ticket von Sylvester, dass ein anderer Rechner aus dem Cluster per SSH nicht erreichbar sei. Kurz auf den Rechner erfolgreich per SSh eingeloggt hätte ich das Ticket eigentlich mit der Begründung “cannot reproduce” ablehnen müssen. Eigentlich. Denn ich hatte ja die Fehlermeldungen zu den Soft Lockups auf der Shell gesehen und bin von Natur aus ein wenig zu gutmütig. Ich unterrichtete Ewok von meinem Plan, es nun einmal mit einem Kernel Update zu versuchen – wenn auch nicht ohne vorher bei Sylvester ein zugegebenermaßen etwas zu selbstgefälliges “Told you so” fallen zu lassen. Also kurz neuen Kernel her, alle Kisten rebootet und beiden kurz eine Nachricht zukommen lassen, dass ich damit so weit durch war. Ticket geschlossen.

Wer als Infrastruktur-Mensch arbeitet oder jemals gearbeitet hat weiß, dass das Empfangen von Dank jetzt nicht unbedingt zur Jobbeschreibung gehört, allerdings gibt es bisweilen auch das grobe Gegenteil und dann werde ich doch ein bisschen angesäuert. So auch in diesem Fall.

Nachdem ich mich also – entgegen anders definierte Prozessstruktur – aus Entgegenkommen gegenüber den betroffenen Entwicklern und um des lieben Friedens willen darum gekümmert hatte, brummt mein Handy mit einer Mail vom Ticketsystem. Jemand hatte in das geschlossene Ticket einen Kommentar geschrieben. Jemand war Sylvester und der Kommentar war, dass der Docker Dienst sich nicht starten ließe. Ich bat ihn darum, dafür bitte ein neues Ticket aufzumachen, da dieses bereits geschlossen sei. Aber wer jetzt glaubt, man würde mir mit Verständnis für einen Ticket-Workflow begegnen, der das einzige ist, was einen Admin vom Wahnsinn trennt, der irrt sich gewaltig.

Dass das Ticket dann eben noch nicht hätte geschlossen werden dürfen, meinte Sylvester. Und dass ich hier die Workflow-Verletzung begangen habe weil ich das Kernel Update nicht im Ticket vermerkt habe – wo es ja eigentlich schon von Anfang an nicht das passende Ticket gewesen war…

Ich entschuldigte mich an dieser Stelle natürlich brav dafür, dass ich durch meine Nichteinhaltung der Prozesse für eine solche Unklarheit bezüglich des Workflows gesorgt hatte, und das ein solches Missverständnis in Zukunft hoffentlich nicht mehr vorkommt. Das war es dann eben mit dem Entgegenkommen.

Wem meine Reaktion zu hart vorkommt, dem sei an dieser Stelle gesagt, dass es nicht das erste Mal war, sondern es eine analoge Situation bereits mit Netzwerkproblemen bei Docker-Overlay-Netzwerken gegeben hatte, die ein Dev, der mit Docker arbeitet ja nicht nachvollziehen oder reproduzieren können muss, da er von Natur aus kein Netzwerkadministrator ist. Und da der Netzwerkadministrator nunmal nicht per Container verschifft, kann sie das Problem nunmal nicht eigenständig reproduzieren. Aber das ist eine andere Story und zwar eine so anstrengende, dass ich sie euch ersparen möchte.

So, ich gehe dann mal Regenbögen in meine pinke Kaffeetasse kotzen und dabei die Melodie von Jeopardy summen.

PS: Mein Kollege ist einfach der Beste! Der hat mir eine Daddy’s Little Monster Tasse besorgt – jetzt fehlt mir nur noch ein Baseballschläger mit der Aufschrift “Good Night” xD (Wer es nicht versteht googele jetzt bitte mal nach Harley Quinn)

 

Da brat mir doch einer nen Treiber!

Da brat mir doch einer nen Treiber!

Heute hat eine Fehlersuche der in meinen Augen etwas absurderen Art stattgefunden:

Ein Kollege (einer meiner liebsten deshalb habe ich ihm geholfen), nennen wir ihn einfach mal Skippy, beklagte sich darüber, dass bei seinem Notebook der Suspend-Modus nicht funktioniert. Dabei handelte es sich um ein 15 Zoll Notebook mit separater Nvidia-Grafikkarte eines namhaften Herstellers, dessen 13-Zoll-Variante ohne Gaminggrafik und Schnickschnack ich benutze.

Die betroffene Distribution war ein Ubuntu 16.04 – aber auch unter 15.04 hatte es schon nicht funktioniert. Nach dem suspend ging der Laptop von alleine wieder an und der Bildschirm blieb schwarz. Mit föhnenden Lüftern betätigten sich die Geräte als Heizung, was auch zwei andere Kollegen mit denselben Geräten unter Ubuntu 15.irgendwas und Debian stretch bestätigen konnten.

Ich erinnerte mich, dass ich anfangs ganz ähnliche Probleme gehabt hatte, dass es allerdings bei mir schon seit langem reibungslos funktionierte, und dass es bei mir außerdem ein BIOS-Update mit einem Fix zum Thema suspend gegeben hatte. Also betreute ich Skippy psychologisch, während er das BIOS-Update von Mitte letzten Jahres herunterlud und installierte. Leider ohne Effekt.

Da das halbe Internet auf ähnliche Probleme stieß aber niemand eine befriedigende Lösung dazu anbieten konnte, verdächtigte ich natürlich zunächst die bösen proprietären Treiber der Nvidia-Grafikkarte und wir versuchten, diese abzuschalten. Da das im BIOS nicht ging (und es sowieso im BIOS keine Optionen zu irgendeiner Grafikkarte gab) hatten wir immerhin Glück unter Ubuntu ein funktionierendes prime-select vorzufinden. Einer von euch muss mir bei Gelegnheit dringend mal zeigen, wie ich ein PCI-Device zur Laufzeit einfach mal vom Bus kicken kann…

Naja leider war es wohl nicht die böse Nvidia-Grafik und es blieb unklar, warum es bei mir als einziges funktionierte. Nachdem beim suspend/hibernate auch immer eine Warnmeldung des Ethernet-Controllers zu sehen war kam irgendwann dann irgendjemand auf die Idee, dass wir ja noch ein Device mit bösen prorietären Treibern in der Suppe schwimmen hatten: die Broadcom-WLAN-Karte.

Nun bin ich ja ein besonderer Freund von nicht-Intel WLAN-Karten, da die unter Linux ja bekanntlich so gut funktionieren *hust*. Naja auf jeden Fall funktionierte die bei meinem Notebook auch mehr schlecht als recht und machte immer wieder ärger weshalb ich – Moment mal – permanent mit entladenem wl-Modul herumlaufe und es nur bei echtem Bedarf lade, denn im Büro hänge ich ja sowieso am Kabel. Aber das muss ein Zufall sein. Bitte lass das ein Zufall sein, liebes Universum, denn wer schafft es so banane zu sein, dass man sowas so verkackt?

Es kam, wie es kommen musste: rmmod wl, und schwupps, suspend verhält sich wie es soll und schon immer getan hat. *facepalm*

Wer jetzt so wie ich glaubt “nimmste das in die suspend-Skripte mit auf und fertig” hat sich leider getäuscht, denn es ist unmöglich herauszufinden, wo jetzt der suspend-Knopf von so einem Unity oder Gnome3 oder wasauchimmer hinzeigt. Fest steht der systemd-logind ist es nicht und wenn ich DBus anfasse bekomme ich ausschlag.

Naja wer weiß, Skippy suspendet jetzt von der Shell aus und für alles andere findet sich vielleicht irgendwann noch ein Developer, der ne schlaue Idee hat. Was bin ich froh, dass mein i3 keinen Suspend-Button hat…