"memtest86+" - meine Rettung...

Diese Woche hatte ich zahlreiche Schreckminuten - eine Kernelpanic nach der nächsten... obwohl genau diese Konfiguration eine Uptime von >450 Tagen hatte und immer problemlos funktioniert hat.

Ich habe den Linux-Kernel des Hosts auf meinem VServer-System getauscht (von 2.6.22.18 auf 2.6.26.2) und auch das Update von Debian "Etch" nach "Lenny" vollzogen.

Stutzig wurde ich als der neue Kernel auch ein "Segfault" nach dem nächsten (verschiedene!) meldete...

Ein "memtester"-Aufruf im laufenden Betrieb unter Linux brachte sehr schnell eine Kernelpanic... Ein memtest86+ bestätigte meine Vermutung: Nach wenigen Sekunden hatte memtest86+ schon RAM-Fehler festgestellt (im Bereich um 305MB).

Nach dieser Erkenntnis habe ich den ersten RAM-Riegel ausgebaut und den 2ten in die erste Bank gesteckt. Dann nochmal einen memtest86+ und einen memtester unter Linux gemacht - alles ohne Probleme. Jetzt läuft mein Server wieder mit mageren 1000MB RAM - aber er läuft wieder.

Fazit: Auch wenn man Markenspeicher eines renommierten Herstellers verwendet kann es nach 3-4 Jahren auch zu Problemen kommen - oder die Staubschicht auf dem RAM und der RAM-Bank war etwas zu hoch ;)

Und zum Abschluss noch ein Kernel-Zitat:
"Eeek! page_mapcount(page) went negative! (-1)".

"Freitag der 13." Server-Upgrade (dist-upgrade)

Ich habe es gewagt an einem "Freitag den 13." ein Update von einigen meiner Linux-VServer von Debian 4.0 ("Etch") auf Debian 5.0 ("Lenny") zu machen.

Zu meiner Überraschung lief das ohne größere Probleme. Hier ein paar Notizen was so aufgetreten ist:

Neues Layout der Konfiguration von Apache2
Unter /etc/apache2/ hat sich einiges getan. u.a. ist die Datei /etc/apache2/apache2.conf kürzer geworden und einiges aus dieser Datei ist in das Verzeichnis /etc/apache2/conf.d gewandert. Das finde ich wirklich besser als vorher.

klogd mit sysklogd machten im Linux-VServer Probleme
klogd wollte im VServer einfach nicht starten. Hierfür gibt es eine einfache Lösung: einfach stattdessen rsyslog verwenden. Man kann sogar in der Datei /etc/rsyslog.conf den Eintrag "imklog" auskommentieren, da ein Linux-VServer ja kein Kernel-Logging benötigt.

neues PHP5 memory_limit
die php.ini von PHP5 hat jetzt ein memory_limit von 128M

Trac 0.11
Trac hat mich etwas mehr Zeit gekostet, da sich die Konfiguraton gegenüber der Version 0.10 etwas geändert hat. Vorher habe ich Trac in Verbindung mit FastCGI verwendet. Bei der Version 0.11 habe ich mich für modpython entschieden. Natürlich musste ich noch das WebAdmin-Plugin aus meinem "EggCache" löschen, da dieses Plugin seit 0.11 Bestandteil von Trac geworden ist.
Die Trac "Datenbank" muss mit dem Programm trac-admin und dem Kommando "upgrade" auf den neuesten Stand gebracht werden. Man sollte auch noch das Kommando "wiki upgrade" verwenden um die Standard-Wiki-Seiten auf die neue Version zu heben.

Subversion
Bei Subversion lief bis auf ein älteres Repository alles ohne Probleme. Das besagte Repository hatte das "bdb"-Layout, verwendete also das Berkeley-DB Backend und kam noch aus der Migration von Debian 3.1 ("Sarge"). Jetzt gab es beim Zugriff über den Apache (mod_dav_svn) eine Fehlermeldung. Als ich ein Dump (via svnadmin) von diesem Repository machen wollte kam ein bdb-Versionskonflikt Version 4.4/Version 4.6 zutage.
Abhilfe schaffte hier ein "svnadmin recover". Hiernach konnte ich ein "svnadmin dump" von dem Repository machen. Dann habe ich ein neues Repository angelegt (natürlich wie empfohlen "fsfs") und habe den Dump eingefahren. Et Voilà... das Repository funktioniert jetzt wieder tadellos.

Der Rest
Die restlichen Programme wie munin, mercurial, apt-cacher usw. machten beim Upgrade keinerlei Probleme.

Jetzt habe ich "nur" noch 6 Linux-VServer mit Debian 4.0 ("Etch") die ich dann auch noch irgendwann mal migrieren sollte... Im November gibt es wieder einen "Freitag den 13." - bis dahin habe ich hoffentlich schon die Zeit gefunden und alle VServer brav migriert.