Webhosting-Ausfall demeter
Incident Report for lima-city Webspace
Postmortem

Wir bei lima-city geben uns große Mühe, ein stabiles und zuverlässiges Webhosting für unsere Kunden anzubieten - denn das ist unsere Aufgabe und dafür werden wir bezahlt. Leider gibt es dabei auch immer wieder Dinge, die nicht so gut laufen, und so ein Problem trat am Freitag, 7.6. und Samstag, 8.6.2019, auf. Wir möchten uns vielmals für die Unannehmlichkeiten entschuldigen und erklären, was das Problem war und wie wir es für die Zukunft lösen.

Am Samstag, den 8.6.2019, informierte uns das Monitoring gegen 12:18 über einen Ausfall auf dem Webhosting-System “demeter”. Die dort gehostete Test-Seite für das Monitoring war seit 12:10 nicht mehr erreichbar. Ein kurzer Überblick auf dem System zeigte, dass PHP-FPM, der Server-Dienst, der PHP ausführt, nicht gestartet war.

Im Normalfall prüfen automatische Systeme (monit) die PHP-FPM-Prozesse, führen auch Test-Scripts auf allen PHP-Versionen aus, und leiten Neustarts ein, wenn es Unstimmigkeiten gibt. Das war zu dem Zeitpunkt schon mehrfach der Fall und die automatischen Neustarts (über zwei verschiedene Methoden, “soft” und “hart”) waren nicht erfolgreich. PHP-FPM beendete immer mit einem “Exit code 254”. Eine kurze Google-Suche danach ergab nicht allzu viel nützliche Informationen, denn der Fehler taucht nur einmal in den Suchergebnissen auf. In dem Fall war das Problem, dass die root-Partition voll war, aber das war bei uns nicht der Fall. Der freie Speicherplatz auf der root-Partition, genauso wie alle anderen Partitionen, wird vom Monitoring überwacht und war nicht voll.

Trotzdem wollte sich PHP-FPM nicht zum Starten überreden lassen. Das Log zeigte einen “Bad file descriptor”. Der Blick fiel auf AppArmor, aber auch da war nichts zu finden. Dann dämmerte es langsam: es ist “fast” der Speicherplatz, nämlich die Inodes (Dateisystemeinträge), welche alle belegt sind. Auf den Webhosting-Servern benutzen wir für /tmp eine separate Partition mit einem eigenen Dateisystem, das wir in den Namespace, in welchem PHP-FPM ausgeführt wird, mounten. Wir isolieren also die temporären Dateien in /tmp in einer eigenen Partition von allen anderen Dateisystemen. Und auf dem /tmp-Dateisystem waren alle Dateisystemeinträge aufgebraucht, obwohl noch ausreichend Speicherplatz vorhanden war. Ein einzelner Kunde hatte eine riesige Menge an winzigen Dateien angelegt, und damit alle Dateisystemeinträge aufgebraucht. Speicherplatz war aber noch ausreichend frei. Da nun aber /tmp in dem Namespace, in dem PHP-FPM läuft, nicht mehr schreibbar war, konnte PHP-FPM auch keine temporäre Datei anlegen und verweigerte den Start.

Nachdem das Problem gefunden war, war die Lösung ganz einfach: diese Dateien löschen, und PHP-FPM startete um 12:50 problemlos und machte keinen falschen Ton mehr.

Nach unseren Erkenntnissen trat das Problem auch schon am Freitag für einen kürzeren Zeitraum auf. Dort wurden allerdings durch andere Kunden zufällig Dateisystemeinträge freigegeben, so dass das Problem sich von selber löste. Dort war nur ein kurzer Ausfall zu beobachten, aber andere Kunden berichten, dass sie keine Dateien in /tmp anlegen konnten (was z.B. auch PHP-Scripte, die Plugin-Installation von Wordpress, Datei-Uploads etc. beeinträchtigt hat). Tatsächlich wurde schon vor dem Problem am Samstag Recherche in den Fehler gesteckt, aber es gab noch keine wesentlichen Erkenntnisse. Man muss auch zugeben, dass das Monitoring von Inodes schon zu den Basics gehört und wirklich ein dummer Fehler ist.

Unsere dauerhafte Lösung ist bereits umgesetzt und beinhaltet:

* einem Script, das die Anzahl der temporären Dateien pro Kunde auf der /trmp-Partition prüft und ab einer gewissen Anzahl startet, Dateien zu löschen

* als Backup-Lösung: einem Monitoring mit Paging, sofern 99% aller Inodes aufgebraucht sind

Ein ähnliches Problem haben wir übrigens auch im Update KW23 gelöst bzw. beschrieben, bei dem ein ähnliches Problem auf dem tmpfs für die Sessions auftreten konnte: [https://blog.lima-city.de/2019/06/updates-kw23/](https://blog.lima-city.de/2019/06/updates-kw23)

Wir entschuldigen uns für die Unannehmlichkeiten, welche den Kunden auf diesem Webhosting-Server entstanden sind. Unsere garantierte Verfügbarkeit von 99,9% für den Monat Juni haben wir dabei klar unterschritten, so dass jeder Kunde auf dem Server auf Wunsch von uns eine Erstattung der Monatsrechnung erhält. Wir werden alle Kunden auf dem Server diesbezüglich informieren.

Posted Jun 09, 2019 - 12:48 CEST

Resolved
Zusätzliches Monitoring und Scripte, um dem Problem rechtzeitig automatisch entgegenzusteuern wurden installiert.
Posted Jun 08, 2019 - 13:54 CEST
Monitoring
Das Problem ist gefunden und behoben, jedoch handelt es sich um eine Situation, die ein Kunde auslösen kann. Wir prüfen derzeit, wie wir verhindern können, dass Kunden die Situation erneut erzeugen können.
Posted Jun 08, 2019 - 13:10 CEST
Investigating
Wir untersuchen ein Problem auf dem Webhosting-Server demeter, auf dem PHP-FPM nicht mehr läuft und sich auch nicht starten lässt. Auf PHP-Anwendungen wird dort die Fehlermeldung "Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Apache/2.4 Server" angezeigt
Posted Jun 08, 2019 - 12:37 CEST
This incident affected: Webhosting (Webserver).