* nick1 (~nick1@nick1.users.quakenet.org) hat #winboard betreten
<nick1> Hey
<nick2> ho
* nick1 (~nick1@nick1.users.quakenet.org) hat #winboard verlassen
<nick3> let's go
Für “Zak McKracken 2 - Between Time and Space” gibt’s zwar schon einige Spiegel-Server, doch seit gerade bietet auch winboard.org das Spiel zum Download an.
Nach unserer Server-Umstellung von Winboard (siehe z.B. “winboard.org - Auf zu neuen Servern“), stieg auf einmal Server02 aus.
Im Logfile tauchten jede Menge Einträge der Art:
Dec 1 11:00:58 server02 kernel: ip_conntrack: table full, dropping packet.
auf.
Diese Meldung sagt eigentlich nur aus: da werden mehr IP-Verbindungen benötigt, als vom System zur Verfügung gestellt werden können.
Die Folge sind Verbindungsprobleme über das Netzwerk zum Server.
Nach dem Ermitteln des Verbindungs-Limits mit:
# sysctl net.ipv4.ip_conntrack_max
net.ipv4.ip_conntrack_max = 65536
lässt sich das Limit dann ganz einfach mit:
# sysctl -w net.ipv4.ip_conntrack_max=131072
net.ipv4.ip_conntrack_max = 131072
höher setzen.
Und damit das auch nach einem Neustart noch entsprechend eingestellt ist, erweitert man einfach die Datei /etc/sysctl.conf um den Eintrag:
net.ipv4.ip_conntrack_max=131072
Nach einer Umstellung mit Hindernissen lief das Forum von winboard.org eigentlich sehr gut. Die Auslastung war niedrig, die Serveranbindung schnell, alles im grünen Bereich.
Doch vor ca. 15 Minuten dann wieder die Hiobsbotschaft: Server down. (Unsere Vermutung: ein Defekt des SATA-Controllers).
Wieder der Hauptserver des Forums.
Und wieder einen Support-Auftrag an den Hoster.
Und wieder warten. Mal sehen, wann das Board wieder oben ist.
Alle anderen Bereiche: download.winboard.org, video.winboard.org, blog.winboard.org, wiki.winboard.org, … laufen aber. Und hoffentlich auch dauerhaft
Edit
1 Stunde später: Da war Hetzner mal so richtig schnell. Server komplett neu, HDs und NICs ausgetauscht. Server läuft wieder. Grund für den wiederholten Ausfall waren laut Support-Mitarbeiter Temperatur-Probleme der CPU.
Wird wohl Zeit, dass wir die Serverüberwachung wieder an den Start bringen…
Das wird mal wieder ein arbeitsreiches Wochenende. Winboard migriert auf eine neue Serverstruktur.
Aktuelles dazu werden wir im Winboard-Blog veröffentlichen.
Hier noch der: Info-Post von Pascal zum Thema.
Feedback und Anregungen bitte: hier
Und für den, den es interessiert, was “hinten” rauskommen soll:
Die Kategorie winboard.org wurde von mir bisher leider nicht so wirklich befüllt.
Ich werde meine Blogging-Aktivitäten zum Thema winboard zukünftig verstärken, werde dazu dann aber auf dem neuen Winboard-Blog unter http://blog.winboard.org dokumentieren, was ich für veröffentlichungswürdig halte.
Und falls ich mich dort doch nicht sooo regelmäßig melden sollte, die anderen Mitglieder des Winboard-Teams sind da sicherlich fleißiger. *g*
Also: reinschauen
Eines (noch nicht einmal kalten) Abends im Februar:
Stefan ist auf dem Weg durch die allabendlich zugeschickten Sysinfomails. Da fand sich doch in der Statusnachricht eines Winboard-Servers die Netstat-Zeile:
tcp 0 0 *:1666 *:* LISTEN 21853/r0nin
Also der Hinweis, dass da seelenruhig eine Backdoor auf dem Server vor sich hinlief.
Ich, gar nicht mehr so seelenruhig per SSH eingeloggt, war leider einmal zu schnell, der “kill -9 21853″ war schneller abgesetzt als der Gedanke an die Analyse des Prozesses. Mist. Also dann half wohl nur manuelle Forscherarbeit.
Hier der ausführliche Bericht zur Jagd auf die bösen Bit-Buben:
Manchmal verstehe ich manche Entscheidungen einiger Debian-Paketmacher nicht. Ich wollte gerade einen Winboard-Server von einer selbstgebauten httpd-2.0 auf die von Sarge zur Verfügung gestellten 2.0er-Pakete umstellen. Und da der Server einigen Traffic hat, sollte sich die Worker-MPM um die Apache-Prozesse kümmern.
Hier, wie in Apache-Downgrade auf winboard.org schon angedeutet, das vorläufige Ergebnis des Downgrades:
Zuerst die gute Nachricht: Das Speicherleck scheint gestopft, der Server ist bisher nicht wieder ausgestiegen 
Der Wermutstropfen: Wie vorher beim Upgrade auf 2.2.2 schon anders herum zu beobachten, liegt die Serverlast nach dem Downgrade auf die 2.0er Version grundsätzlich (teilweise sehr viel) höher 
Tolles Dilemma: entweder Abstürze mit Apache 2.2 oder eine hohe Serverlast mit Version 2.0 des Indianers.
Mein Fazit: erst einmal abwarten, wie der Server unter Vollast mit mehr als 900 Usern reagiert.
Nach dem letzten erzwungenen Abbruch des Apache-Downgrades (siehe Kernel-Update mit Hindernissen), ist die Umstellung nun endlich durch.
Grund für den Downgrade von Version 2.2.2 auf 2.0.59 war ein Memory-Leak. Dies verursachte nach ca. 1 bis 2 Tagen wiederholt, dass der Hauptspeicher vollief, bis dann der Kernel anfangen musste, httpd-Prozesse abzuschießen. Und wir waren dann gezwungen, den Server abzuschießen *g*.
Zuerst hatte ich den PHP5 (war in Version 5.1.4 installiert) in Verdacht, aber eine Umstellung auf die 4.4.3 brachte (außer einem subjektiven Performance-Gewinn) keine Abhilfe.
Da es etwas schlecht ist, den Fehler auf dem Echtsystem zu debuggen (da sind i.d.R. zwischen 500 und 800 User online), der Fehler aber anscheinend nur unter Dauerlast auftritt (die ich auf einem Testsystem nicht habe), stand der Entschluss, den Apache “downzugraden” fest.
Nach dem erfolgreichen Kompilieren nahm ich eine Parallel-Installation zum Produktivsystem vor und passte die Konfiguration an.
Der Switch auf die neue alte Version verlief danach fehlerfrei. Die Grundlast scheint in etwa gleich geblieben zu sein - jetzt fehlt bloß noch der Dauerbelastungstest.
Ich werde über dessen Ausgang berichten (spätestens dann, wenn’s wieder zu Fehlern kommt ).
Wenn jemand ähnliche Erfahrungen mit Speicherproblemen im Apache 2.2.2 hat, wäre ich dankbar über jegliche Informationen zu dem Thema. Auf Apache.org habe ich nichts hierzu gefunden, und im Upgradelog auf 2.2.3 wurde auch kein derartiger Fehler beschrieben.
