Blog

S4F5

20100106 0:05 MESZ

Ich wollte die Maschine eigentlich nur rebooten. Aber der ging schief, weil ich mal wieder Grub und FSTAB durcheinandergebracht habe. Kein Wunder, wenn die Kiste über 300 Tage Uptime hat.

Also die Maschine remote ins Recovery-System versetzt. Nach 20 Minuten ist immer noch kein Recovery da. Also 24/7-Support verständigen. Beim Anruf: "Sie rufen außerhalb der Geschäftszeit an." Wie?

Nochmals auf die Remote-Adminstration gesehen. Eindeutig steht da "24/7 Support". Mit einem Sternchen: 07:00 Uhr bis 24:00 Uhr.

Also nochmals: Server4You wirbt mit einem 24/7-Support der dann nur 17h am Tag erreichbar ist. Na bravo!

Also Ticket eröffnet, die Maschine soll bitte ins Recoverysystem.

20100106 07:15 MESZ

Es tut sich nix. Lediglich dass das Ticket weitergeleitet wird. Also den Service angerufen. 1:30 in der Warteschleife dann "vielen Dank dass Sie uns angerufen haben, alle Leitungen sind besetzt, bitte versuchen Sie es später nocheinmal" (klick). Hallo? Was soll das denn? Kostenpflichtige Hotline die dann einen auch noch nach 2 Minuten Bezahlung einfach rauskickt? Das kann es dann doch wohl nicht sein, oder?

Ist aber tatsächlich so. Mit einer Wahrscheinlichkeit von sagen wir mal ca. 10% bekommt man einen Techniker, dann aber innerhalb von 2 Minuten, ansonsten wählt man sich aber die Finger wund.

20100106 09:30 MESZ (ca.)

Maschine ist im Recoverysystem, aber ich kann mich nicht einloggen. Ich bekomme einmal telefonisch durch, aber der Mitarbeiter dort kann mir eigentlich nicht weiterhelfen. Ich sage, ich versetze den Rechner einfach neu ins Recoverysystem.

Übrigens kam keine Meldung dass das Recovery-System nun verfügbar ist.

20100106 13:02 MESZ

Das Recovery-System ist endlich verfügbar. Ich starte den Filsystemcheck.

Nochmals: Es dauerte 4h(!) um den Rechner in das Recoverysystem zu versetzen. 4h, das bedeutet ca. 8 Umkreisungen vom Space-Shuttle. Binnen 4h kommt man mit der Bahn von München nach Frankfurt und mit dem Flugzeig nach Moskau. 4h in einer schnellebigen Welt wie dieser ist mehr als eine Ewigkeit. Für einen ISP ist das nicht mir hundsmiserabel, das ist geradezu destruktiv.

20100107 01:00 MESZ

(Ich habe in der Zwischenzeit geschlafen, irgendann muss man ja auch mal ins Bett.)

Die Einstellungen in der Maschine werden von mir gefixt und die Maschine aus dem Recoverysystem genommen.

Fast instant ist die Maschine nicht mehr per Ping erreichbar. Der Reboot lässt allerdings auf sich warten.

Funktioniert die Kiste jetzt oder funktioniert sie nicht? Liegt ein Fehler bei Server4You vor oder nicht?

Man kann es nur ahnen, im Frontend steht "Reboot startet". Mal davon abgesehen dass das schlechtes Deutsch ist (einen Reboot startet man nicht, einen Reboot löst man aus) weiß ich nicht, was ich davon zu halten habe.

20100107 01:20 MESZ

Die Maschine ist rebootet, ich glaube es kaum! Im Frontend steht 1:11, die Uptime der Maschine ist aber von 10 Minuten später. Time-Warp?

Leider funktioniert die Kiste nicht wie sie soll. Sieht fast so aus, als wäre das Filesystem RO gemountet.

Keine Ahnung wieso, ich kann mir nur denken, dass ich /etc/fstab wiederum verbockt habe. Aber immerhin bin ich nimmer auf das eher unbrauchbare Toolset von S4Y angewiesen.

20100107 01:55 MESZ

FSTAB nochmals gefixt und rebootet. Liegt es an diesen Einstellungen oder woanders dran?

Inittab auf 4 gestellt damit die Services nicht mitgestartet werden.

Die Maschine ist so schnell rebootet dass ich gar nicht mitbekomme, wie sie runterging. Also nach einem Reset sollte es eher 0 Zeit brauchen bis die Kiste von Reset auf Ping kommt.

20100107 02:00 MESZ

Das Root-Filesystem ist nun RW. Aha, nun muss ich nur noch rausfinden, was ich verbockt habe.

Jetzt heißt es rumfummeln, ändern und ständig rebooten bis die Kiste so hochkommt wie sie soll.

Ein Reboot dauert übrigens nur ca. 50s, von "reboot (return)" bis PING und 10s später geht auch der Login.

20100107 02:40 MESZ

Ich weiß jetzt, was ich verbockt habe. Die Mount-Optionen vom root-FS stellt man nicht nur in /etc/fstab ein, sondern muss das auch in die Boot-Parameter aufnehmen, da der remount sonst nicht klappt (anderer Modus). Damit bleibt das Filesystem sonst readonly.

Dank ext3 geht das aber auch mit tune2fs:

So, nun funktioniert es endlich wie es soll, also init wieder auf 2 zurückgestellt und rebootet.

20100107 02:45 MESZ

Maschine rebootet nicht, ist anscheined beim Reboot hängengeblieben. Anscheinend hat das BIOS etc. manchmal Probleme dass die Kiste anstartet! Das wäre eine Erklärung warum auch das Recoverysystem nicht funktioniert.

• Der Software-Reboot funktionierte auch nicht.
  
• Recovery-System funktioniert aber.
  

20100107 09:50 MESZ

Nach einigen Malen hin- und herkonfigurieren funktioniert die Kiste nun. Ich musste sie mehrfach ins Recovery-System versetzen usw. bis ich den richtigen Dreh herausfand:

• Maschine ins Recovery versetzen.
  
• Maschine wieder aus dem Recovery versetzen.
  
• Dann einige Minuten warten.
  
• Dann Reset auslösen.
  
• Und lange (20 Minuten und mehr) warten.
  

Irgendwann pingt die Maschine wieder. Das ist sehr unbefriedigend, da man dann 1h oder länger darauf warten kann ob sich etwas tut. Und wenn sich nichts tut weiß man nicht, ob sich nichts tut weil sich auf der Maschine nichts tut oder ob sich nichts tut weil der Reset bzw. Reboot nicht tut.

Hintergrund

Was war genau los?

Syslogd hat die Maschine unendlich verlangsamt. Das liegt einerseits an der sehr langsamen Platte, andererseits an den vielen fsync()-Calls die syslogd macht.

Bei mir war das so, dass ein fsync() manchmal 1 Minute und länger gebraucht hat. Syslogd() ist leider so blöd und sammelt die eintreffenden Daten nicht, sondern macht nach jeder(!) Zeile einen fsync(). Wenn der Fsync 1 Minute braucht und man 10 Zeilen schreiben muss, dann dauert das 10 Minuten.

Warum braucht der fsync() so lange? Das liegt einerseits an einer grottenlangsamen Platte (seek). Andererseits daran, dass Linux unsinnigerweise data=ordered eingestellt hat. Bei einem fsync() muss so der gesamte Inhalt des Plattencache auf die Platte geschrieben werden. Das ist gleichbedeutend mit einem Aufruf vom Shell-Kommando "sync", das auch durchaus mal mehrere Minuten brauchen kann.

Wenn man nicht "noatime" an hat, viel mit Dateien arbeitet die gelesen werden und außerdem viele Fuzzeldateien im System geschrieben werden, dann kann es also sein, dass syslog einfach nicht mit dem Schreiben hinterherkommt. Und dann blockieren die Programme, da der syslog-Buffer ständig überläuft.

SSH bricht dann z. B. die Verbindung ab, weil es nicht loggen kann (timeout). Und vieles andere wird ultralangsam.

Abhilfe schafft, einen anderen Modus einzustellen. Data=writeback ist aber schlecht, da dann das Journal ausgeschaltet wird.

Ergo bleibt nur data=journal übrig. Übrigens sowieso die beste und sicherste Methode. Der fsync() muss dann nur warten, bis die Daten im Journal stehen und kann dann weitermachen. So jedenfalls die Theorie. Ob es klappt werde ich sehen.

Nachteil:

Wenn man nun etwas wie einen News-Server betreibt der viele kleine Dateien schreibt, dann wird das superlangsam. Wenn man aber etwas hat, das die Dateien hauptsächlich nur liest, dann wandert ja wenig ins journal, insebsondere wenn man die Option "noatime" setzt, etwas das man sowieso nur selten benötigt.

Eine Sache sei erwähnt: Hat man eine SSD oder irgendeinen anderen schnellen Speicher, dann kann man das Journal durchaus auch auslagern. Das Journal von Ext3 muss nicht im selben Filesystem liegen! Da das Journal dann unabhängig ist, bekommt man so wesentlich höhere Duchsatzraten auf den eigentlichen Datenspeicher.