Wenn ein Container-Update den Kernel überholt
Geschätzte Lesezeit: 7 Minuten
Wichtigste Erkenntnisse
1. Ein Dienst, der läuft, arbeitet nicht automatisch.
2. Fehlermeldungen zeigen dorthin, wo etwas auffällt — nicht dorthin, wo etwas kaputt ist.
3. Container teilen sich den Kernel.
Inhaltsverzeichnis
- Wie es aufgefallen ist
- Die Fehlermeldung, die in die falsche Richtung zeigt
- Die Eingrenzung
- Warum das ausgerechnet ein NAS trifft
- Der Rückweg, der keiner war
- Die Lösung lag im Installationsskript
- Drei Dinge, die ich mitnehme
Wie es aufgefallen ist
Ich war auf der Suche nach etwas völlig anderem: Ein paar meiner umgewandelten Filme waren nach der Verarbeitung größer als vorher, und das wollte ich verstehen. Beim Blick in die Datenbank fiel mir eine Zeile auf, die ich fast überlesen hätte.
Die Warteschlange stand auf zwei.
Zwei Dateien, die ich Mitte Juli in den Eingangsordner gelegt hatte, warteten seitdem darauf, verarbeitet zu werden. Der letzte erfolgreich umgewandelte Film datierte auf den 9. Juli. Seitdem: nichts.
Es gab keine Fehlermeldung. Keine Mail, keine Push-Nachricht, keinen roten Punkt in irgendeiner Oberfläche. Der Dienst lief, meldete sich gesund, und tat einfach nichts. Das ist die unangenehmste Sorte Ausfall — die, bei der alles danach aussieht, als würde es funktionieren.
Die Fehlermeldung, die in die falsche Richtung zeigt
Im Protokoll fand ich dann die Ursache. Dachte ich.
ConnectorAgent: DockerMod 'FFmpeg FileFlows Edition:2' not installed
Alle elf Sekunden dieselbe Zeile. Der Dienst wollte jede Datei verarbeiten, stellte fest, dass ein Baustein fehlt, und legte sie zurück. Elf Sekunden später von vorn. Tagelang.
Die naheliegende Erklärung wäre eine kaputte Konfiguration. Und tatsächlich fand ich einen Schalter, der auf false stand und die Installation dieses Bausteins komplett unterband. Umgelegt, Dienst neu gestartet, Problem gelöst.
War es natürlich nicht. Die Meldung kam weiter. Aber jetzt stand eine zweite darüber:
Installing DockerMod: 0002_FFmpegFileFlowsEdition.sh Installing BtbN FFmpeg into /app/common/ffmpeg-static... tar: bin/ffmpeg: Cannot open: Function not implemented tar: bin/ffprobe: Cannot open: Function not implemented
„Function not implemented” beim Entpacken eines Archivs. Das ist eine Meldung, die keinen Sinn ergibt. Kein Speicherplatzproblem, keine fehlenden Rechte, kein defektes Archiv. Der Systemaufruf, den tar benutzen wollte, existiert schlicht nicht.
Die Eingrenzung
Solche Meldungen prüft man am besten mit dem kleinstmöglichen Test. Also: eine Datei anlegen, einpacken, wieder auspacken.
mkdir -p /test/q && echo hallo > /test/q/x tar cf a.tar q && rm -rf q && tar xf a.tar
Im betroffenen Container: Cannot open: Function not implemented. In einem schlichten Alpine-Container auf demselben Gerät: läuft durch.
Damit war klar, dass es nicht am Dateisystem liegt und nicht am Speicher, sondern am Container selbst. Der nächste Blick galt also dem, was sich verändert hatte.
| | | | |
|---|---|
| Basis des Containers | Ubuntu 26.04 |
| C-Bibliothek | glibc 2.43 |
| tar-Version | GNU tar 1.35 |
| Kernel des Geräts | 4.4.302 |
Da ist es. Ein modernes Userland auf einem Kernel von 2016.
GNU tar in aktueller Fassung nutzt Systemaufrufe, die in Kernel 4.4 noch nicht existieren. Der Kernel antwortet ehrlich mit „nicht implementiert”, tar bricht ab, der Baustein wird nicht installiert, der Dienst verweigert die Arbeit. Eine Kette aus vier Gliedern, von denen nur das letzte eine Meldung erzeugt — und die zeigt in die falsche Richtung.
Das Container-Image war am 29. Juli aktualisiert worden. Genau der Tag, an dem die Verarbeitung stehenblieb. Wer mehr über die Risiken von Updates und Rollbacks erfahren möchte, liest am besten hier.
Warum das ausgerechnet ein NAS trifft
Fertige NAS-Geräte fahren oft sehr alte Kernel. Nicht aus Nachlässigkeit, sondern weil der Hersteller Treiber für seine eigene Hardware pflegt und ein Kernel-Sprung dort Arbeit und Risiko bedeutet. Ein Gerät, das jahrelang Sicherheitsupdates bekommt, kann trotzdem auf einem Kernel-Stand von vor acht Jahren laufen.
Docker verdeckt das. Ein Container bringt sein eigenes Userland mit, und deshalb hält man ihn intuitiv für unabhängig vom Wirtssystem. Ist er aber nicht. Der Kernel wird geteilt. Läuft im Container ein Programm, das mit modernen Systemaufrufen gebaut wurde, und der Wirt kennt sie nicht, bricht es zusammen — oft nicht beim Start, sondern erst bei einer einzelnen Aktion irgendwo tief im Ablauf.
Das ist die Falle: Der Container startet, meldet sich gesund, die Weboberfläche geht. Nur eine Funktion darin ist tot.
Der Rückweg, der keiner war
Naheliegende Lösung: zurück auf die vorherige Version. Das alte Image lag noch auf der Platte, ich habe es mit einem Namen versehen, in der Konfiguration eingetragen und den Container neu erstellt.
Version '25.12.9.6135' is out of date, please upgrade to continue. Startup failed
Neustartschleife. Die Anwendung hatte beim Update ihre Datenbank auf ein neueres Schema gehoben, und die ältere Version weigert sich, damit zu arbeiten.
Das hätte ich vorher bedenken müssen. Eine Datenbank-Migration ist bei den meisten Anwendungen eine Einbahnstraße. Wer zurück will, braucht ein Backup von vor dem Update — nicht nur das alte Image. Ich habe sofort zurückgestellt, der Dienst lief nach zwei Minuten wieder im kaputten, aber stabilen Zustand.
Ähnliche Rückschläge bei Aktualisierungen hatte ich auch schon in anderen Projekten erlebt, beispielsweise bei meinem Mailserver-Setup.
Die Lösung lag im Installationsskript
Wenn tar nicht kann, muss tar eben nicht müssen. Ich habe mir angesehen, was das Skript überhaupt prüft, bevor es installiert:
BTBN_DIR="/app/common/ffmpeg-static"
function is_btbn_installed {
[ -x "$BTBN_DIR/ffmpeg" ] && [ -x "$BTBN_DIR/ffprobe" ]
}
Zwei Dateien, ausführbar, im richtigen Ordner. Mehr will es nicht wissen. Liegen sie da, meldet es „bereits installiert” und ist zufrieden — die Zeile mit tar wird nie erreicht.
Also habe ich sie ihm hingelegt. Auf dem Notebook heruntergeladen, entpackt, hochgeladen, den Ordner als Bind-Mount in den Container gehängt, neu gestartet.
Ergebnis nach anderthalb Minuten: Verarbeitung läuft, Grafikkarte bei 80 Prozent Auslastung, erster Film in Arbeit. Nach sechs Tagen Stillstand.
Der Bind-Mount hat einen angenehmen Nebeneffekt: Der Ordner liegt außerhalb des Containers und überlebt damit jedes künftige Update.
Drei Dinge, die ich mitnehme
1. Ein Dienst, der läuft, arbeitet nicht automatisch. Meine Überwachung prüft, ob Container laufen und ob sie sich gesund melden. Beides war erfüllt. Was gefehlt hat, ist eine Prüfung auf Fortschritt: Steht die Warteschlange seit Tagen still, obwohl etwas drin ist? Genau das baue ich jetzt nach.
2. Fehlermeldungen zeigen dorthin, wo etwas auffällt — nicht dorthin, wo etwas kaputt ist. „DockerMod not installed” klingt nach Konfiguration. Die eigentliche Ursache stand eine Ebene tiefer und nur im vollständigen Protokoll. Wer beim ersten plausiblen Treffer aufhört, repariert das Falsche.
3. Container teilen sich den Kernel. Das weiß man, und trotzdem denkt man es im Alltag nicht mit. Bei einem Gerät mit altem Kernel ist ein Image auf sehr neuer Basis ein echtes Risiko — und das Symptom ist nicht „startet nicht”, sondern „macht eine bestimmte Sache nicht mehr”. Wer das Muster kennt, spart sich viel Suchen.
Der auffälligste Teil bleibt für mich trotzdem, dass es sechs Tage gedauert hat. Nicht wegen des Fehlers. Sondern weil ich in dieser Zeit mehrfach auf dieses Gerät geschaut habe und nichts gesehen habe, was mich stutzig gemacht hätte.
FAQ
Frage: Warum wurde mein Dienst nicht aktiv, obwohl kein Fehler angezeigt wurde?
Antwort: Dienste können aktiv erscheinen, aber dennoch keine Fortschritte machen, wenn eine erkannte Funktion nicht verfügbar ist.
Frage: Wie kann ich zukünftige Probleme mit Container-Updates vermeiden?
Antwort: Überwachen Sie nicht nur den Dienststatus, sondern überprüfen Sie auch Fortschritte und die Kompatibilität des Kernels mit aktuellen Container-Images. Ein Update- und Rollback-Playbook hilft dabei, wie ich es in diesem Artikel erläutere.
