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)

 


2 thoughts on “Soft Lockup yourself!

  1. Sylvester nimmt unterschwellig wahr, dass Penylane ihm haushoch überlegen ist, kann das aber für sich selbst nicht zugeben und kennt keine sinnvolle Reaktionsmechanismen. Sylvester ist jetzt eigentlich frustriert und reagiert mit Schikane; blöd für Pennylane, führt zu kotzen in die Kaffeetasse (buaäh). Sylvester braucht Zeit ….abwarten….

  2. Was haben wir uns früher über den bleistiftspitzenden Buchhaltungstyp mit Ärmelschoner amüsiert, zum Beispiel beim “Hauptmann von Köpenick”.
    Menschen, die “Prozesse” eingehalten haben.

    Dumm – und vor allem peinlich – nur, daß gerade “wir” es sind, die die “Bleistiftspitzer 4.0” konstituieren. Gnaden- und humorloser, als es die Bürokratie im Falle des Schusters Wilhelm Vogt je war.

    Und sei froh, daß Ihr nicht auch noch “SCRUM” bekommt, zur Erheiterung:
    http://if-blog.de/hb/ganz-agil-vorbei-am-ziel/

    Zuguterletzt:
    Sei froh, daß Deine Jungs mit “Docker” spielen. Ja klar ist es scheiße, aber mit “VMWare” und ähnlichem Unrat kommst Du vom Regen in die Traufe.

Leave a Reply

Your email address will not be published. Required fields are marked *