Gefangen im Deadlock
Letzte Woche warf es einige zig DSL-Kunden bei Neuanmeldungen immer wieder raus. Schon einige Minuten nach Auftreten des Problems schrillte das Alarmsystem los: Ein ungewöhnliches Anmeldemuster liege vor.
Einer der PPP terminierenden LNS-Server hatte ein Problem: Die Konfiguration des jeweils neu entstandenen Interfaces kam nicht zum Abschluß. Das zugehörige Script hing fest.
Nach einiger Zeit lief es dann spontan weiter und führte die gewünschten Aktionen aus. Auf dem angegeben Interface natürlich, aber nicht zwangsweise an dem Interface, das wirklich gemeint war. Denn der Router des Nutzers hatte schon lange aufgegeben.
Was war passiert?
Aus einem nachträglich nicht mehr definitiv feststellbaren Grund war das Locking der Initialisierung durcheinander gekommen. So wartete das Script auf die Freigabe, endlich allein an systeminternen Datenbeständen ändern zu dürfen.
Vermutlich war das Überschreiben von Kernelspeicher der Auslöser. Dinge, die sonst in Sekundenbruchteilen erfolgen, hatten sich nun quer gelegt.
Dies passierte zum allerersten Mal. Trotzdem mußte eine kurzfristige effektive und langfristig stabile Lösung gefunden werden.
Kurzfristig effektiv ist es natürlich, die betreffenden Scripte komplett zu killen. So weit, so einfach.
Aber was passiert, wenn sich eine solche Situation wiederholen sollte? Langfristig muß man mit allem rechnen, also auch damit, daß ein normaler Systemcall praktisch ungewöhnlich lange zur Abarbeitung braucht. Deswegen wurden alle Scripte mit einem automatischen Timeout versehen:
$SIG{ALRM} = sub { die "alarm\n" };
alarm 3;Das mag brutal sein, aber lieber ein fehlkonfiguriertes Interface als ein Totalstillstand für alle neuen Verbindungen.
Die Maschine beruhigt sich schnell, legte aber kurz danach einen Reboot hin, weil die Kernelspeicher zu sehr kaputt war.
Es besteht die ernsthafte Hoffnung, daß diese Ursache beseitigt wurde. Trotzdem bleibt dieser Sicherungsmechanismus aktiv. Für alle Fälle.