Beiträge von A.Topal

Sehr merkwürdig, meine Tools haben nicht angeschlagen und ich kann nichts auffälliges in den Logs erkennen :-??

Ja, sorry, das war mein Fehler beim Upgrade. Sollte eigentlich keiner merken

Gestern ist eine virtuelle Maschine, die ebenfalls auf diesem Server läuft, abgestürzt und hat dabei offenbar hohe Last erzeugt. Leider war aus den Log-Dateien nicht mehr ersichtlich, was dazu geführt hat. Heute Nachmittag, um 16:55, gab es dann eine extrem hohe Last hier auf camp-firefox.de, aber das hat sich nach 10 Minuten von selbst wieder gelegt und das Log schaut ganz normal aus. Leider ging das ganze auch so schnell, dass ich die Benachrichtigung durch das Monitoring-Tool erst gesehen habe, als die Lastspitze schon vorbei war. Es kann natürlich sein, dass wir eine unglaublich hohe Anzahl von Besuchern hatten, aber das kann ich erst morgen sehen, weil die Logs immer erst am folgenden Morgen verarbeitet werden.

Danke jedenfalls euch allen für die Infos hier.

In den USA gelten, andere, sinnvollere Regeln im Umgang mit urheberrechtsgeschütztem Material als hier. Du musst nur reagieren, wenn dich jemand auf die Verletzung aufmerkam macht, und das Material entfernen, du bist nicht gleich haftbar wie hier.

Zitat von Boersenfeger

OK, war hier nicht bekannt. Ich weiss nur, das, wenn ich Beiträge per Ausrufezeichen melde, diese schnell geschlossen bzw. entsprechend der Meldung "behandelt" werden.

Das verdanken wir unseren sehr aufmerksamen Moderatoren :wink:
Aber der nächste Punkt auf meiner ToDo-Liste ist die E-Mailbenachrichtigung bei gemeldeten Beiträgen, dann kann der Thread hier entfallen.

Zitat von Lendo

Kadir, danke für deine Erläuterungen. Ich hoffe, du hast Zeit, deine XEN- und Debian-Reparaturschritte auch wieder schön detailiert in deinem Blog nachvollziehbar aufzuschreiben? Wenn es schon so wenig Dokumentation zu XEN gibt ...

Eine wirklich gute Idee :wink:

Aus unbekanntem Grund hat sich der Server neugestartet, aber alles deutet darauf hin, dass es einen Stromausfall gab. Ich warte noch auf Antwort von meinem Hoster.

Edit: Es war kein Stromausfall. :-???

Bei so einer Community mache ich das gerne

Dann noch ein Wort zum Ausfall letzte Woche (Vorsicht, sehr technisch): Eigentlich wollte ich den Server bereits letzte Woche upgraden, aber schon beim ersten Befehl fiel mir auf, dass einige Partitionen read-only gemountet waren, darunter auch /root /etc. Nachdem ich die Logs durchgegangen war, war klar, dass die 2. Festplatte im Raid defekt war. Eigentlich ist das ja kein Problem, dafür haben wir schließlich ein Raid. Wenn eine Festplatte ausfällt, macht die andere weiter. In diesem Fall leider nicht. Auf dem Server sind drei Partitionen vorhanden, wie ich dann feststellen musste, war Partition A nur auf der defekten Festplatte vorhanden, weil das Raid aus einem unbekannten Grund Festplatte 1 abgeschaltet hatte, aber nur für Partition A. Partition B und C waren dagegen nur auf Festplatte 1 vorhanden, denn dafür wurde die defekte Festplatte deaktiviert, wie es auch sein sollte.

Also folgender Zustand:

Part.  | Platte
A             2
B             1
C             1

Einen solchen Zustand sollte es in einem korrekten Raid eigentlich nie geben. Denn so kann man nicht einfach eine der beiden Festplatten entfernen. Noch schlimmer: Die Partitionen waren schon seit 2 Tagen read-only geschaltet worden und damit waren auch alle Backups seit 2 Tagen veraltet. Ich musste also erst ein Backup der Server erstellen, übers Netz verteilen, dann die Festplatte 1 mit der defekten Festplatte synchronisieren und dann nach einem Austausch der defekten Festplatte die neue Festplatte synchronisieren.

Das wirft natürlich eine Reihe von Fragen auf: Die wichtigste, "wie konnte das Raid in einen solchen Zustand kommen?", kann ich leider nicht mehr beantworten, die Logs dazu waren schon seit längerem gelöscht. Die zweitwichtigste Frage, "Warum hat der Server nicht darüber informiert?", kann ich hingegen beantworten. Das Monitoring für die Festplatten war deaktiviert. Das Basis-System war ein vorkonfiguriertes Image vom Hoster und ich hatte mich darauf verlassen, dass so etwas wichtiges wie Fesplatten-Monitoring funktionieren würde. Das war selbstverständlich ein grober Fehler meinerseits.

Zwar lässt sich das Ganze leider nicht rückgängig machen, aber zumindest für die Zukunft deutlich besser absichern. Inzwischen läuft ein Monitoring der Festplatten auf zwei Ebenen, einmal direkt auf der Hardware und einmal ein Monitoring des Raid-Zustandes. Zumindest bleibt die Erkenntnis, dass Backups einen auch in diesen Situationen noch die Nerven behalten lassen.

Hallo zusammen, ich wollte ja schon länger mal schreiben, was eigentlich in den letzten Wochen passiert ist. Dazu muss ich vorausschicken, dass das Problem heute nicht damit zu tun hatte, zumindest nicht direkt.

Die Kurzversion: Ich habe ein Upgrade der Server durchgehführt und das schien zwar geklappt zu haben, aber ein automatisch geplanter Neustart am frühen Morgen hat dann einen Fehler provoziert und die Lösung hat mehrere Stunden in Anspruch genommen. Inzwischen läuft wieder alles ganz normal.

Lange Version: Gestern Nacht habe ich unseren Server, der eigentlich eine virtuelle Maschine ist, und den Wirtsserver von Debian Etch auf Debian Lenny aktualisiert. Das Upgrade der virtuellen Maschine lief auch recht problemlos, weil ich das schon drei Mal getestet hatte. Das Upgrade des Wirtsservers hätte eigentlich sogar noch weniger problematisch sein sollen, weil auf dem praktisch kein Dienst außer dem XEN-Hypervisor läuft. Ausgerechnet der hat dann offenbar das Problem verursacht. Denn heute Morgen sollte ein Skript die VMs herunterfahren, ein Backup erstellen, und wieder hochfahren. Das Herunterfahren und Sichern lief, aber die VMs wurden nicht mehr hochgefahren.

Das Problem: Beim Upgrade wurden die Xen-Pakete mit dem alten Kernel beibehalten, aber die restlichen Pakete wurden aktualisiert. Das führte dann dazu, dass die Xen-Skripte eine ältere Version von Python erwarteten als installiert war und daraufhin den Betrieb verweigerten. Nach einem Upgrade des Kernels waren die Pakete dann zwar kompatibel, aber die Netzwerkkonfiguration in XEN hatte sich geändert: Die VMs liefen zwar ganz normal, hatten aber keine Verbindung mehr nach Außen. Leider ist die Doku dazu recht lückenhaft und so hat es mehrere Stunden gedauert, bis ich den Fehler erkannt und eine Lösung gefunden hatte.

Die schlechte Nachricht: Die schlechte Dokumentation von Xen wird wohl bei jedem Upgrade zu Fehlern führen. Die gute Nachricht: Debian-Upgrades stehen nur alle paar Jahre an.

Das Forum war leider von gestern Nacht bis heute Abend nicht verfügbar. Grund war der Defekt einer Festplatte im Raid. Wie es aussieht, haben wir keine Daten verloren, falls doch etwas fehlen sollte, stehen aber Backups bereit. Ich werde später noch über die kuriosen Zufälle schreiben, die zu diesem Ausfall geführt haben.

Ja, nur dass sich jetzt eines unserer Backups verabschiedet hat. Argh

Das Hotel hat WLAN

Das Problem ist persistent, und ausgerechnet jetzt bin ich außer Landes, werde mich erst Dienstag Nacht darum kümmern können

Sollte wieder klappen, wir haben ein paar Adressen auf der Spammer-Liste, das war eine davon.

Hmm, das würde eher meine erste These stützen, dass der Neustart am korrupten Dateisystem schuld ist. Da passt der Absturz um 3.40 nicht ins Bild. Merkwürdig jedenfalls, dass es immer nur nachts passiert. Ach, es ist wirklich ärgerlich, dass das Dateisystem betroffen ist, so wird natürlich auch das Log abgeschaltet, und ich kann nichts nachvollziehen

Das Aufschlussreiche hier ist die Uhrzeit. War das bei dir vor oder nach 4 Uhr?

Danke für den Screenshot, das ist aufschlussreich. Offenbar passiert der Fehler nicht beim Neustart. Hmm, das macht das ganze noch verzwickter

Sorry, das war so nicht geplant, aber jetzt konnte ich das Problem etwas besser eingrenzen. Kurz gesagt: Der Server hat morgens nach dem Neustart Schwierigkeiten, und ich werde versuchen, festzustellen, was da genau passiert.

Die Langfassung: Morgens um 4.05 startet der Server neu und offenbar mag das eine der laufenden Anwendungen nicht und korrumpiert das Dateisystem. Nach dem Neustart findet das System dann das korrupte Dateisystem, setzt alles auf read only und wartet auf einen manuellen fsck. Nach dem manuellen fsck läuft alles wieder normal, offenbar bis zum nächsten Neustart. Aber nicht konsistent, meistens läuft es normal, manchmal korrumpiert der Neustart das System. Leider gibt das Log praktisch nichts her. Ich werde mir jetzt genauer anschauen, was währenddessen passiert.

Vielen Dank noch für die Email übrigens, hab Sie leider erst bekommen, als die Seite dann wieder lief.

Gestern Mittag musste ich ein Backup neu laufen lassen, was wir normalerweise immer nachts laufen laufen lassen. Aber der Speicherplatz war übergelaufen und ich wollte kein Risiko eingehen. Heute Morgen ist dann der Server aus unbekanntem Grund teilweise abgestürzt. Ich vermute, dass es am Dateisystem lag, was jetzt auch erstmal repariert ist, aber leider sind die Daten, die ich habe, nicht sehr aufschlussreich, wie das halt so ist, wenn das Dateisystem wegbricht