Kurz vor meinem Urlaub bemerkte ich zufällig, dass domaininformation.de nicht mehr online war und musste es auch einen Monat so belassen. Der Provider KNDS (Betreiber der Domain hostingdomain.de) hat dafür gesorgt das der Account gesperrt wird. Ich habe das leider nicht mitbekommen, da mein Emailprovider (freecity.de) einen defekten Spamfilter eingerichtet hat, der stillschweigend die Emails von KNDS in's Nirvana wandern läßt.

Der Grund für die Sperrung ist das vermeintlich kaputte PHP Script, welches für die Generierung dieser Seiten verantwortlich ist. KNDS hat zwar einen Aufwand betrieben um mein Script als Verursacher auszumachen, konnte aber keine weiteren Details liefern.

Ich habe dann als Kandidat für das Problem eine physikalisch kaputte MySQL Tabelle vermutet. Mir ist vor Monaten aufgefallen dass ich auf eine Tabelle für die Fehlerlogs keinen Zugriff mehr habe. Ich habe daraufhin KNDS per Email gefragt warum die Tabelle kaputt ist, und gebeten sie entweder zu reparieren oder zu löschen. Wegen der damals schon kaputten Emailkommunikation, hat KNDS die Tabelle nicht repariert, weil sie noch eine Bestätigung von mir wollten. Ich habe die kaputte Tabelle einfach hingenommen, weil seit mindestens einem Jahr kein ernster Fehler mehr geloggt wurde und ich ohnehin an einer Reimplementierung in PHP5 arbeite.

Ich habe die kaputte Tabelle (auf die ich keinen Zugriff hatte) und sämtliche Folgeerscheinungen in KNDS Verantwortungsbereich geschoben. KNDS hingegen macht mich dafür verantwortlich dass ich wissend eine kaputte Tabelle akzeptiert habe und mein Script dadurch den Server zu sehr belastet hat. Zusätzlich will KNDS mir die Schuld aufdrängen (was aus ihrer Sicht deren gutes Recht ist) in dem meine Domain für den Transfer gesperrt wird. Also zahle ich die Serviceleistung und gut ist.

Nachdem ich endlich meine Domain auf einem neuen Server hatte und keine Verpflichtungen gegenüber KNDS hatte, habe ich hier natürlich über den einmonatigen Ausfall geschrieben. KNDS liest ihn und fordert mich auf ihn zu löschen oder zu ändern. Damit KNDS keinen Anwalt einschalten muss verfasse ich diesen ausführlichen Artikel der die Tatsachen möglichst ungetrübt wiedergibt.

Wegen der erneuten Reaktion seitens KNDS habe ich nochmal über mein Script meditiert, denn auf dem neuen Server verursacht es keine Last. Ich bin zu dem Schluss gekommen, dass meine Theorie mit der kaputten Tabelle falsch sein muss.

Meine Vermutung war eine Endlosschleife in der Fehlerbehandlung. Die Fehlerbehandlung schreibt sämtliche Fehler in die kaputte Tabelle. Also wird beim Schreiben ein weiterer Fehler ausgelöst, der wieder die Fehlerbehandlung aufruft. Das ist sozusagen eine rekursive Endlosschleife. Der Denkfehler dabei ist, dass das Schreiben in die Tabelle mittels mysql_query() geschieht. Mysql_query() löst aber bei einem MySQL Fehler (der beim erfolglosen Schreiben in die kaputte Tabelle auftritt) keinen Fehler in PHP aus. Also gibt es so auch keine Endlosschleife.

Also kann ich doch irgendwo einen jahrelang unentdeckten Fehler haben. Ich habe auf dem neuen Server den Fall mit der kaputten Tabelle rekonstruiert um dasselbe Szenario zu erhalten. Die Endlosschleife blieb aus, aber mir fiel eine neue Fehlerquelle auf. Da der jetzige Server mit PHP5 läuft werden bei PHP4-Scripte an vielen Stellen Warnungen über veraltete Syntax geworfen. Wenn nun in der Fehlerbehandlung oder vor der korrekten Initialisierung aller Objekte aufgrund der neuen Syntax eine Warnung geworfen wird, haben wir die gefürchtete Endlosrekursion. Nachdem KNDS noch PHP4 betreibt kommt dies nicht in Frage. Was aber in Frage kommen kann ist ein Update das KNDS vorgenommen hat und so (per php.ini) bestimmte Konstrukte bereits in PHP4 Warnungen werfen. Nachdem ich keinen Zugang zur KNDS Umgebung habe kann ich das auch nicht verifizieren.

Falls obige Theorie diesmal zutrifft, stellt sich wieder die Frage wer Schuld ist. KNDS weil sie PHP geändert haben, oder ich weil mein Script für die ursprüngliche Konfiguration geschrieben wurde. Letzendlich ist es egal, weil domaininformation.de nicht mehr von KNDS gehostet wird, und KNDS kein Script laufen hat, welches den Server unangenehm belastet. Das es soweit kommen musste liegt leider daran dass die Kommunikation bereits am Anfang versagte. Hätte ich mitgekriegt dass sich die PHP Konfiguration ändert, so hätte ich mein Script prüfen und den Fehler bereits vor den ersten Servertiefs beheben können.