In der Welt der Systemadministration gibt es eine ungeschriebene Regel: Wenn alter Code funktioniert, rührt ihn niemand an. Doch was passiert, wenn dieser Code scheinbar funktioniert, aber bei zunehmender Skalierung massiv versagt? Genau dieses Szenario hat das Canonical Support-Team kürzlich eindrucksvoll demonstriert. Ein Fall, der zeigt, wie schnell ein routinierter Systembefehl zum Performance-Alptraum werden kann – und warum das Durchkämmen von verstaubtem C-Code manchmal die einzige Lösung ist.
Der Vorfall: Wenn getent zum Stolperstein wird
Der Ausgangspunkt des Problems war ein scheinbar banaler Vorgang: die Abfrage von Benutzer- und Gruppeninformationen unter Linux. Der Standardbefehl dafür lautet getent. Ein Kunde von Canonical nutzte diesen Befehl in Kombination mit dem nssdb-Backend, einer Legacy-Lösung, die Kontodaten aus Berkeley DB-Dateien liest, anstatt auf LDAP oder lokale Flatfiles zurückzugreifen.
In Umgebungen mit einer überschaubaren Anzahl von Einträgen funktioniert das reibungslos. Bei diesem Kunden war das System jedoch auf über 24.000 Benutzer- und Gruppeneinträge angewachsen. In dieser Größenordnung wurde die Enumeration – also das Durchlaufen und Auflisten aller Einträge – so extrem verlangsamt, dass das System für die eigentlichen Workloads praktisch unbrauchbar wurde. Alternativen hatte der Kunde bereits getestet, sie boten nicht das benötigte Performance-Profil.
Code-Archäologie: Der Abstieg in 12 Jahre alten Code
Die wahre Herausforderung bei diesem Ticket bestand nicht darin, einen aktuellen Kernel oder eine neue Software-Version zu debuggen. Das Problem verbarg sich in libnss-db, einer Komponente, deren C-Quellcode seit über einem Jahrzehnt nicht mehr nennenswert verändert worden war. Standard-Troubleshooting war hier nicht zielführend.
Der Support-Ingenieur von Canonical musste tief in die Mechanik der Berkeley DB einsteigen und den Kontrollfluss des veralteten Codes nachvollziehen. Das Ergebnis dieser Code-Archäologie war ein klassischer, aber oft unterschätzter Logikfehler: Die Bibliothek öffnete und schloss die Datenbankdateien bei jedem einzelnen Enumerationsschritt erneut, anstatt die Verbindung für den gesamten Durchlauf offenzuhalten.
Der Auslöser war ein fehlerhaftes Verhalten rund um das stayopen-Flag. Anstatt dieses Flag zu respektieren und die Verbindung zum Keep-Alive zu bewegen, riss der Code die Verbindung nach jedem Lookup ab. Die Konsequenzen sind mathematisch leicht erklärbar, in der Praxis aber verheerend: Ein einziger Durchlauf löste 48.422 wiederholte Lesezugriffe auf der Festplatte aus. Das ist Performance-Mord pur.
Der Fix und sein Weg nach Upstream
Die Lösung war so elegant wie folgenschwer: Durch das Beibehalten der offenen Datenbankverbindung während der gesamten Enumeration entfielen die redundanten Disk-Reads. Die Performance erholte sich sofort auf ein akzeptables Niveau.
Doch mit dem Patch war es nicht getan. Der Fall wurde an das Canonical Sustaining Engineering-Team übergeben, um den Bug formal zu tracken und die Änderung Upstream zu pushen – inklusive eines Launchpad-Bugs und Rückportierungen in aktuelle Releases wie Ubuntu Noble. So wird verhindert, dass der Fehler in zukünftigen Versionen wieder auftaucht.
Eigenanalyse: Das unsichtbare Risiko der Infrastruktur-Wartung
Dieser Fall ist ein hervorragendes Lehrstück, das über den reinen Bugfix hinausgeht. Er offenbart drei zentrale Probleme der modernen IT, die in der Praxis oft übersehen werden:
Das „Works on My Machine“-Phänomen bei Skalierung: Ein Logikfehler, der bei 100 Einträgen vielleicht nur wenige Millisekunden kostet, skaliert exponentiell. Alte Code-Basen werden oft jahrelang als „stabil“ deklariert, einfach weil sie in kleinen Umgebungen nicht auffallen. Erst wenn ein Unternehmen massiv wächst, bricht das Fundament ein.
Das Dilemma des verwaisten Legacy-Codes: Wer pflegt Software, die seit 12 Jahren unverändert ist? Die Open-Source-Community hat hier oft ein Blind Spot. Beliebte, aktive Projekte werden ständig verbessert, aber fundamentale, unsichtbare Bibliotheken rottet vor sich hin, weil ihnen die Feature-Attraktivität fehlt. Wenn dort ein Fehler auftritt, gibt es oft keine aktiven Maintainer mehr, die sich sofort darum kümmern.
Der reale Wert von Enterprise-Support: Hier zeigt sich die Differenzierung zwischen kostenlosen Distributionen und bezahltem Support. Ohne ein Ubuntu Pro mit Support-Abo wäre dieser Kunde mit seinem Problem wahrscheinlich allein geblieben. Standard-Workarounds oder Konfigurationsänderungen hätten hier nicht geholfen. Es brauchte Ingenieure, die bereit und in der Lage sind, alten C-Code zu lesen und zu patchen.
Fazit
Die Geschichte um den libnss-db-Bug ist ein Reminder daran, dass Stabilität nicht gleichbedeutend mit Fehlerfreiheit ist. Manchmal lauert der größte Performance-Killer in den ältesten Ecken des Systems. Für Unternehmen, die auf Linux setzen, bedeutet das: Infrastruktur ist nicht einfach „gesetzt und vergessen“. Es braucht entweder die interne Expertise, um bei Skalierungsproblemen tief in den Kernel und die Userland-Bibliotheken einzusteigen – oder einen verlässlichen Partner, der genau das im Rahmen eines Support-Vertrags leistet.
Quelle: Ubuntu Blog
