Warum mein Webserver hängen blieb, nachdem er in Fefes Blog verlinkt worden war
Zugegeben, es ist äußerst ärgerlich, wenn ein Webserver hängen bleibt, wenn er mal auf Fefes Blog oder im Heise Newsticker verlinkt wurde, wie bei meinem heute wieder. Und ich habe gerade zwei Stunden mit Fehlersuche zugebracht. Aber das (bisherige) Ergebnis der Fehlersuche ist durchaus aufschlußreich. [Nachtrag 2]
Ja, ich weiß, das macht für einen Informatiker einen ganz schlechten Eindruck, wenn ein Server in die Knie geht, sobald er mal belastet wird. Zumal das ja schon mehrfach passiert ist. Die Ursachen sind aber durchaus interessanter (und lehrreicher) als man so vorab glauben sollte. Und noch bemerkenswerter: Es waren jedesmal andere Ursachen.
Kurz zur Erläuterung: Der Webserver, auf dem meine Blogs und meine E-Mail laufen, hat natürlich den Zweck, das ganze möglichst preisgünstig zu machen, und auch die Administrationszeit, die ich da zusammen mit einem guten Kumpel reinstecke, ist begrenzt. Natürlich, mit Geld geht alles, aber die Kunst ist, es mit wenig Geld und wenig Zeitaufwand hinzukriegen (zumal ich in die Inhalte der Blogs schon mehr Zeit reinstecke, als ich eigentlich will). Die Maschine ist eine Vereinsmaschine und dient dem Zweck, die Webserver von allen Vereinsmitgliedern (so ein Haufen wilder Informatiker, die sich seit Jahren aus wilden Zeiten kennen) als virtuelle Maschinen zu betreiben. Deshalb kann ich da auch nicht machen und drehen (und vor allem weglassen) was ich will, sondern die Einstellungen sind so, daß sie auch die Anforderungen aller Mitglieder erfüllen (müssen). Und momentan bekommen wir das eigentlich mit sehr wenig Geld ziemlich gut hin.
Zunächst will ich aber mal darauf hinaus, was nicht die Ursache ist: Schiere Überlast. Nein, das ist es nicht. Erstens haben wir uns gerade vor ein paar Monaten erst eine neue Servermaschine gekauft, einen richtig guten Hobel mit ausreichend Speicher, Rechenleistung und Netzanbindung, um ganz locker und leicht auch eine Last zu tragen, wenn Heise, Fefe und Twitter auf einmal kommen. Zweitens, und das ist das interessantere, weil die Kiste dann, wenn sie Webseiten nicht mehr ordentlich ausliefert, nicht etwa überlastet ist, sondern im Gegenteil die Serverprozesse mehr oder weniger zum Erliegen kommen, also gar nichts mehr tun. Also mehr Stillstand als Last.
Allerdings will ich auch nicht verhehlen, daß uns das indirekt zweimal tatsächlich dazu geführt hat, daß die Kiste keinen Speicher mehr hatte, aber nur deshalb, weil wir die Parameter im Apache für die maximale Zahl der Prozesse nicht richtig gedrosselt hatten. Man muß abschätzen, wieviel Speicher man dem Webserver insgesamt zugestehen will, und das durch das dividieren, was man für die Größe eines Prozesses hält, und dann hat man die maximale Anzahl von Prozessen, die man zulassen darf. Da hatten wir uns einmal verschätzt und einmal vergessen, den (viel zu hohen) default-Wert runterzusetzen, was dazu führt, daß bei blockierenden Apache-Prozessen der Mutter-Prozess immer neue Child-Prozesse erzeugt, bis Speicher und Swap komplett dicht sind. Sollte natürlich nicht passieren. Ist aber weder Problem noch Ursache, sondern nur eine Nebenfolge des Problems. Zudem haben wir den Webserver unter anderem aus diesem Grund inzwischen in eine separate virtuelle Maschine ausgelagert.
Warum überhaupt Prozesse? Für den Apache-Webserver gibt es verschiedene Implementierungen der Parallelverarbeitung, im wesentlichen hat man die Wahl zwischen geforkten Prozessen und Threads. Threads wären da eigentlich die angemessenere Wahl, aber wie ich oben schon sagte, wird der Server von vielen Leuten verwendet, und die haben unterschiedliche Webapplikationen, die u.a. auf PHP usw. beruhen. Und nicht alle dieser Apache-Plugins sind thread-safe. Mit der Kombination an Plugins, die wir hier fahren, geht nur die prefork-Variante, bei der ein Mutterprozess eine Zahl von Child-Prozessen anlegt, deren Zahl zwischen einem zu konfigurierenden Minimum und Maximum liegt.
Innerhalb dieser Grenzen werden neue Child-Prozesse erzeugt, wenn eine Web-Verbindung reinkommt, die nicht sofort von einem freien Prozess behandelt wird. Und die Child-Prozesse werden getötet, wenn eine gewisse Zahl davon untätig herumsteht, oder wenn sie zuviel gearbeitet haben (und vielleicht degeniert sind).
Und da liegt der Hund begraben: Wenn wegen hoher (das heißt mehr als das, womit man den Server normalerweise betreibt und testet) Last oder aus anderen Gründen die einzelnen Prozesse zu lange brauchen, um Verbindungen anzunehmen oder dauerhaft blockieren, will der Mutterprozess immer mehr Prozesse anlegen, bis er entweder an das konfigurierte Maximum stößt, oder bis mehr als der physikalische Speicher belegt ist, und die Maschine ins Swappen kommt oder nicht mehr Swappen kann, weil der Swap-Space auch voll ist. Und das ist der Effekt, den man heute (und in einigen Fällen auch schon früher) hier bei diesem Server, aber auch auf anderen Servern beobachten kann, die in die Knie gehen, wenn sie von Heise, Fefe oder sowas verlinkt werden.
Wohlgemerkt, das ist eigentlich keine Überlast, sondern die Folge eines anderen Problems. Bei Überlast funktioniert der Server wieder, wenn die Last nachläßt. Es gibt aber andere Effekte, die das länger hinziehen können (und mitunter schwer zu debuggen sind).
Solch einen Effekt hatten wir schon letztes und vorletztes Jahr. Da war es ein statistisches Problem. Mein Blog nutzt (noch, es geht mir gewaltig auf den Wecker und Leser meines Blogs wissen, daß ich gerade an was baue, was anders funktioniert) WordPress und das basiert auf PHP. Dazu verwendet PHP einen sessionstore, indem Werte für die Sessions abgespeichert werden können und auf den die Prozesse zugreifen. Damit es nicht zu Kollissionen kommt, wird natürlich eine Semaphore verwendet (hab die Details jetzt gerade nicht mehr griffbereit, es war glaub ich mutex). Und da war irgendein Fehler in PHP, es konnte passieren, das unter ganz ungünstigen Umständen zwei Prozesse so gleichzeitig drauf zugriffen, daß sie sich verhakten und blockierten, und die Semaphore auch nicht mehr freigaben. Damit blieben auch alle anderen Prozesse stehen, weil sie auf die Freigabe der Semaphore warteten. Und je mehr Leute auf den Server klicken, desto höher ist einfach die Wahrscheinlichkeit, daß es zu dieser unwahrscheinlichen, aber nicht ausgeschlossenen Blockade kommt. Das Problem tritt also lastabhängig auf, obwohl es mit Überlast oder überhaupt der Leistungsfähigkeit der Maschine nichts zu tun hat. Je mehr Besucher kommen, desto höher ist einfach die Wahrscheinlichkeit, daß zwei ziemlich gleichzeitig kommen.
Mit dem Problem haben wir eine Zeit gekämpft und wüste Workarounds gebastelt. Aber mit dem nächsten Upgrade (und dem Umstieg auf eine andere Linux-Distribution anlässlich des Maschinenwechsels und der Neuorganisation mit virtuellen Maschinen) hielten wir dieses Problem eigentlich für gelöst. Es ist bisher auch nicht mehr aufgetreten.
Heute nun erwähnte Fefe in seinem Blog meinen Artikel über die Kinderpornosperre. (Hätte eigentlich nicht gedacht, daß ein Artikel über eine 2 Jahre alte und tote Sache noch auf soviel Interesse stößt.) Ich saß gerade mit Freunden im griechischen Restaurant und hab’s über das Handy gemerkt, konnte aber nichts machen (außer erstmal fertig zu essen) und nach Hause zu fahren.
Zuerst nahm ich an, daß es wieder das alte Problem mit dem Session-Store ist, weil es von außen exakt so aussah. War es aber nicht.
Es war ein Zusammentreffen mehrerer Effekte, von denen kein einziger für sich betrachtet ausreichend kausal war, die aber in ihrem Zusammenwirken dazu geführt haben, daß der Server nicht mehr funktionierte:
- Auch der neue Webserver verträgt nur eine gewisse Anzahl gleichzeitiger Prozesse. Speichergröße durch Größe eines Prozesses. Und nur so viel Verbindungen gleichzeitig. Denn Apache prefork ist so gebaut, daß jeder Prozess immer nur eine Verbindung gleichzeitig bearbeiten kann. Alle anderen HTTP-Requests müssen warten. Das ärgert den Besucher schon. Wartet man noch länger, gibt es einen Timeout und im Browser eine Fehlermeldung.
- Wir haben beim Umzug des alten auf den neuen Webservers eine Nachlässigkeit begangen und nicht alle Konfigurationsvariablen des Apachen feingeschliffen. Die Default-Werte des Apache bzw. der Linux-Distribution funktionieren so nicht ohne weiteres.
Neben einzelnen Timeout-Werten, die zu hoch eingestellt waren, war das Hauptproblem der Wert für KeepAlive, der auf On stand.
KeepAlive bedeutet, daß der Browser für mehrere Anfragen (er muß ja nicht nur die Webseite, sondern auch Graphiken, CSS usw. holen um eine Seite aufzubauen) die gleiche TCP-Verbindung verwenden kann. Normalerweise (also ohne KeepAlive) würde der Server die Antwort auf die HTTP-Anfrage rausschicken, dann den Socket dicht machen und sodann die nächste Anfrage beantworten. Ist KeepAlive aber aktiv, dann läßt der Server den Socket offen und wartet, ob der Browser noch was will oder die Verbindung von sich aus abbaut. Oder ein Timeout eintritt, der hier bei 15 Sekunden lag.
Aus irgendwelchen Gründen, die ich jetzt nicht mehr nachvollziehen konnte, haben seltsamerweise relativ viele Clients die Verbindung nicht zügig geschlossen. Könnte ne DoS-Attacke gewesen sein, vielleicht ne neue Browsereigenschaft, oder vielleicht habe ich irgendeinen HTML-Fehler, ich weiß es nicht. Es standen jedenfalls alle Apache-Prozesse herum und warteten darauf, daß die Clients die Verbindungen zumachen oder Timeout eintritt. Und das führt eben dazu, daß der Webserver scheinbar keine Anfragen mehr beantwortet, weil eben bei hoher Last die maximale Zahl von Prozessen existiert und nahezu alle dieser Prozesse damit „beschäftigt” sind, bis zu 15 Sekunden zu warten, ob der Browser noch was haben möchte.
Also habe ich KeepAlive abgeschaltet. Und schon legen die Serverprozesse nach Übertragung der Daten von sich aus auf.
Generell würde ich das aber für ein ungünstiges Apache-Design halten, denn es dürfte eigentlich nicht dazu führen, daß der Server mehrere Sekunden lang keine Anfragen mehr bedient. Eigentlich dürften Prozesse nur so lange warten, wie genügend Prozesse für neue Anfragen bereit stehen.
- Erst hatte man kein Glück, und dann kam auch noch Pech dazu.
Leser meines Blogs werden sich erinnern, daß ich bisher auf diesem Blog Danisch.de rechts in der Menüleiste einen RSS-Reader eingeblendet hatte, der die neusten Meldungen aus meinem anderen Blog Forschungsmafia.de präsentierte. Eigentlich sollte das harmlos sein, denn es ist ein gewöhnliches WordPress-Element, das man da plazieren kann. Und hat seit Jahren ordentlich funktioniert. Vorhin hat sich dieses RSS-Reader-Modul aber als fatal und der finale Sargnagel erwiesen.
Warum?
WordPress holt den RSS-Feed immer dann neu, wenn der bisherige, zwischengespeicherte Feed zu alt ist und jemand gerade eine Seite anfordert, für die ein aktueller Feed angezeigt werden soll (weil WordPress ja nur aktiv wird, wenn jemand eine Seite abfragt). WordPress baut also die Webseite (für danisch.de) zusammen, hält aber dann, wenn es den RSS-Feed anzeigen soll, erst einmal an und holt den Feed. In diesem Fall von Forschungsmafia.de. Und so lange von da nichts kommt, geht es nicht weiter. Erst muß Forschungsmafia.de mit dem RSS-Feed antworten.
Nun läuft aber Forschungsmafia.de auf demselben Webserver, nur in einer anderen virtuellen Instanz. Das heißt, wenn auf Danisch.de so viele zugreifen, daß alle verfügbaren Prozesse ausgelastet und blockiert sind, etwa weil viele noch auf den Timeout warten (s.o.), dann liefert der Server auch keinen RSS-Feed für Forschungsmafia.de und somit können die Blogseiten für Danisch.de nicht fertiggestellt werden, weil der Feed fehlt. Dann blockiert jeder Prozess, weil WordPress in jedem einzelnen der Meinung ist, sich jetzt den RSS-Feed holen zu müssen, und dann geht gar nichts mehr, dann blockiert das Ding.
Das heißt, daß der Webserver die Webseiten, die eigentlich (außer dem RSS-Modul) aus der Datenbank geholt und versandfertig sind, nicht rausschicken kann, weil er stehen bleibt, bis der RSS-Feed kommt, der genau deshalb nicht kommt.
Also habe ich auch das RSS-Modul auf Danisch.de aus dem Menü rechts rausgeworfen.
Aktuell läuft wieder alles, was aber auch daran liegen kann, daß es inzwischen nach 23 Uhr ist und damit die Last automatisch zurückgeht.
Sorry, Leute, tut mir schrecklich leid. Wurmt mich natürlich gewaltig, vor allem dann, wenn man etwas schreibt, was viele lesen wollen und die dann nicht drauf zugreifen können. Ärgert mich wahnsinnig. (Und an meinem Geburtstag heute wäre ich wirklich lieber mit Freunden beim Griechen geblieben, als stundenlang den Webserver zu debuggen, zumal ich die anschließende Jazz-Band verpaßt habe. Wer weiß, wie lange es noch Griechen gibt…)
Aber es zeigt immerhin, auf welche Weise eine vermeintlich stabile Software auf unvorhergesehene Weise in einen Fehlerzustand geraten kann, mit dem man so vorher nicht gerechnet hat. Und ich nehme trotz allem für mich in Anspruch, daß ich hier Fehler gefunden habe, die wirklich nicht jeder gefunden hätte – nicht jeder, der Webserver betreibt. Und daß Server so, wie sie mit einer Linux-Distribution kommen, auch nicht direkt stabil sind.
Und nun stellt Euch mal vor, das wäre nicht mein kleines unwichtiges Privat-Blog gewesen, sondern irgendwas wirklich wichtiges. Irgendwas in einem Kernkraftwerk. Oder im Rettungswesen. Oder was mit Aktien- oder Wechselkursen. Telebanking, sowas in der Art. Und obwohl die Kiste ausreichend dimensioniert ist und die Software als robust und erprobt gilt, schaukelt sich dann sowas so hoch.
Vielen Dank übrigens an die Leser, die mich per E-Mail auf die Störung aufmerksam gemacht haben.
Hrmpfz. Peinlich ist es schon. Wurmt mich.
Nachtrag 1:
Ich habe oben geschrieben, daß ich gestern abend während der Störung beobachtet habe, daß die Serverprozesse nach der Auslieferung der Seiteninhalte für längere Zeit im KeepAlive-Modus herumstehen und warten, ob noch etwas kommt, und in dieser Zeit keine neuen Anfragen entgegennehmen können. Obwohl der Server dabei von außen so aussieht, als wäre er überlastet, tut er in Wirklichkeit gar nichts, die Prozesse warten und der Prozessor ist idle, hat also Langeweile. Denn von den Clients (den Browsern) kam dann auch kein Verbindungsabbau, weshalb die Serverprozesse immer sehr lange auf den Timeout gewartet haben. Jeder Prozess war mit der Abarbeitung eines Requests nicht nur den üblichen Sekundenbruchteil, sondern viel länger bis zu etwa 16 Sekunden, belegt.
Ich überlege daher die ganze Zeit, woher das kommen könnte.
Und mir kommt der Verdacht, daß dies auf zwei Arten selbst eine Auswirkung der hohen Last war, die sich selbst aufgeschaukelt hat. Was paradox wäre, denn KeepAlive bei HTTP-Verbindungen wurde nachträglich eingeführt um den Durchsatz zu erhöhen.
Theorie 1 (halte ich für sehr wahrscheinlich): Der Browser verwendet für den Aufbau der Seite wegen des Keep Alive zwar nicht für alles eine neue Verbindung, sondern läßt sie eben offen bis die Seite komplett ist, aber er verwendet trotzdem mehr als nur eine Verbindung, um Inhalte parallel zu holen. Nehmen wir zu Erklärung mal an, der Browser öffnet zwei Verbindungen, A und B. Über A fordert er die Webseite selbst an. Noch bevor die Seite komplett übertragen wurde sieht der Browser schon am Header und im oberen Bereich der Seite, daß Style-Sheets, Javascript usw. zu holen sind, die er schon mal über die neue Verbindung B holen will. Wenn jetzt aber, wie es gestern passierte, neue Verbindungen nicht aufgebaut werden können, weil auf dem Server gerade kein Prozess in den listen()/accept()-Turnus kommt, würde der Verbindungsaufbau für B stecken bleiben, sofern er auf dem Browser nicht sehr sauber und asynchron programmiert ist. Ich könnte mir vorstellen, daß der Browser deshalb auch die offenstehende Verbindung A nach Übermittlung der Seite nicht richtig bedient (also weder Anfragen schickt noch sie schließt) bzw. die Verbindung A einfach vorsorglich ungenutzt offenstehen läßt, bis die Seite endlich vollständig ist, weil alle ausstehenden Requests bereits über B (oder C usw.) verschickt wurden, es für A also nichts mehr zu holen gibt, A aber auch nicht geschlossen wird, weil die Seite noch nicht fertig aufgebaut ist.
Das würde bedeuten, daß es ausgerechnet die hohe Serverlast und die Verzögerung bei der Annahme und Bearbeitung von Verbindungen (siehe auch das RSS-Problem) dazu führt, daß Browser die im KeepAlive-Modus offene Verbindung gerade noch viel länger stehen lassen als üblich – und damit den Server erst recht blockieren. Ausgerechnet das Keep-Alive, was für höheren Durchsatz sorgen soll, würde zu einer Blockade führen.
Theorie 2 (eher unwahrscheinlich, da muß ich noch weiter forschen): Es kam wegen der Blockade der Server dazu, daß eingehende TCP-Verbindungen nicht angenommen wurde, weil die Prozesse nur noch selten dazu kamen, per listen/accept neue TCP-Verbindungen anzunehmen. Deshalb haben viele Clients einen Timeout gehabt und Fehlermeldungen angezeigt. Es wäre denkbar, daß irgendwelche weitverbreiteten DSL-Router das auf NAT-Ebene nicht richtig handhaben (viele DSL-Router haben da Ungereimtheiten) und des deshalb zu Verbindungen kommt, die nur noch von einer Seite (also vom Server aus) offen stehen.
Beide Theorien würden aber dazu führen, daß ausgerechnet der KeepAlive, der ja Effizienz und Durchsatz erhöhen soll, gerade das Gegenteil bewirkt.
Nachtrag 2: Ich hatte oben den Bug mit den verhakten Prozessen beschrieben, der früher wiederholt dazu führte, daß der Server stehen blieb. Daß das im Normalfall so gut wie nie und bei hoher Last dann wiederholt auftritt, hängt auch mit dem „Birthday Paradoxon” zusammen, das aus der Kryptographie bekannt ist. Bei steigender Benutzerzahl steigt die Wahrscheinlichkeit einer Kollision überproportional an, weil es ja nicht auf einen Zusammenstoß zu einem bestimmten Zeitpunkt ankommt (was statistisch linear bzw. unter Berücksichtigung der nicht linear wachsenden Wartezeiten auf Platte, SQL-Server usw. sogar überlinear steigt), sondern jedes beliebige Paar zählt, das kollidieren kann, also die Wahrscheinlichkeit quadratisch ansteigt.
Deshalb kann es sein, daß ein Server jahrelang stabil läuft, und dann plötzlich die Grätsche macht, wenn er stark frequentiert wird. Ohne im eigentlichen Sinne kapazitiv überlastet zu sein.
43 Kommentare (RSS-Feed)
Danke!
Da schließe ich mich doch gleich mal an. Herzlichen Glückwunsch.
Und dank Google-Cache konnte ich den Artikel auch während der Downzeit lesen und hab den Text als PDF gleich weitergereicht.
Mir geht regelmäßig das Messer in der Tasche auf, wenn ich von soviel ministerieller und behördlicher Inkompetenz und Sprach-Inkontinenz, sowie Ignoranz und Machterhalt erfahre.
Danke für die Zeit, den Mut und Zivilcourage, sehr offen mächtigen Personen gegenüberzutreten (U vd L und ihr Netzwerk).
Man, da komme ich mir ja wie ein Geburtstagsgeschenk vor. Ich habe gestern (22.06.) einen Verweis auf Dein Blog bei Udo Vetter gefunden. Vorher habe ich Dich leider verpasst.
Herzlichen Glückwunsch nachträglich! Und zu Deiner Beruhigung (oder was auch immer): meine Prioritäten liegen ähnlich. 😉
So, muss mich mal durch Deine alten Blogartikel wurschteln.
Hallo Hadmut,
Immerhin hast Du wieder was gelernt. Und dank dieses Postings haben auch eine ganze Menge anderer Leute was gelernt (!).
Herzlichen Glückwunsch zum Geburtstag.
Hey Mann! Alles Gute zum Geburtstag!
Ich kann verstehen, daß dir das peinlich erscheint und du es ausführlich erklären willst – und das kannst du ja super. Aber eins ist doch auch klar:
du mußt dich doch hier nicht entschuldigen.
(Habe letztens auf Facebook mitgekriegt, daß du sehr viel gelesen wirst und das Interesse scheinbar auch weiterhin steigt. That’s good!)
Alles Gute zum Geburtstag!
Das beste Geschenk ist ja wohl Dein abgefahrenes Blog, das ich leider erst vor kurzem entdeckt habe. Hat bei mir einen Stammplatz zwischen fefe, taz, netzpolitik und AlJazeera. Vielen Dank und mehr davon.
Danke für Deine Postings und herzlichen Glückwunsch zum Geburtstag, sowie alles Gute. 🙂
Danke für die technische Beschreibung (ich kam via fefe zu Dir).
Soweit man die Basisfakten (Server auf Normalbetrieb konfiguriert, Lasttest auch nur im “normalen” Bereich) nimmt, sind noch andere Situationen denkbar und schon aufgetreten, die nicht mehr mit keepalive in Griff zu bekommen sind.
Du hattest ein abschwellendes Ereignis. Dramatischer sind anschwellende Ereignisse: WebServer im Hochwassergebiet mit internationaler Aufmerksamkeit; sowas.
Es war wohl eine Varinate von nimda: Der (Virus auf PC installiert) wollte sich seine Befehle holen; dazu war eine Liste von URLs dort gecodet. Dummerweise auch einer meiner Server. – Ich will es mal sehr verkürzen: Da kommst Du dann auf die Idee, ob 200 nicht doch besser als 404 ist. Was übrigens -in solchen Situationen zählt man jedes Byte- tatsächlich angemessen war. Da denkt man auch über access.log (abschalten?) nach. Es würde den Kommentar sprengen; ggf. sprich mich per Mail an.
Ich will dann auch mal gratulieren. Herzlichen Glückwunsch!
Herzlichen Glückwunsch, danke fürs Fixen, danke vor allem auch für den wirklich beeindruckenden Blog über den Kreuzzug der Frau von der Leyen.
Ich persönlich halte Apache-Prozesse übrigens für ca. 30 MB zu groß für die Auslieferung verhältnismäßig simpler Blog-Seiten. Ich nehm übrigens nginx und Drupal und kann beides wärmstens empfehlen (aber klar: Einarbeitung und Config nötig).
Herzlichen Glückwunsch!
Danisch gevettert — lulz
Hoffentlich ist dieser Beitrag nicht “to spammy”.
Carsten
—
“Kein Wunder, daß man heute schon Doktortitel für korrektes Abschreiben bekommt.”
Volker Gringmuth
auch von mir herzlichen Glückwunsch. Dank des Artikels von gestern habe ich den Blog entdeckt und auch aboniert. Die Artikel haben, im vergleich zu vielen anderen Blogs, endlich mal etwas gehalt.
Grüße
Hartmut
Wieso machst du die Einblendung des anderen Blogs nicht per Javascript. Wenn das nichts lädt, ist halt gerade nix da, die eigentliche Seite ist trotzdem geladen. So geht das eigentlich auf jeder Seite die Werbung einblendet.
@ini: Weil WordPress das nicht ohne weiteres so hergibt (für das RSS-Modul gibt es halt eine fertige Funktion) und sich häufig Leute darüber beschweren, wenn was mit JavaScript läuft. Außerdem hab ich in JavaScript nur sehr wenig eigene Erfahrung.
In Zukunft werde ich das so machen, daß es nicht mehr über RSS läuft, sondern automatisch bei jeder Änderung die Liste aktualisiert wird.
Die Vermeidung von JavaScript wird sich aber nicht halten lassen, denn ich möchte in Zukunft für bestimmte Daten wie Graphiken, Bilder, Googlemaps-Karten usw. bessere Funktionsmodule haben und da braucht man unvermeidlich JavaScript. Wird also kommen.
> eine Semaphore verwendet
Ahhh! Es heißt *der* Semaphore (“Zeichenträger”)!
Aber danke für die aufschlußreiche Erklärung für den gestrigen Ausfall.
@Geralt: Glaub ich nicht. Man kann von einer deutschen Übersetzung nicht auf das orginal-Geschlecht schließen (im Englischen ist beispielsweise alles neutrum).
Zumal schon mal gar nicht der Semaphore, sondern allerhöchstens der Semaphor (ohne e am Ende). Laut meinem Duden Fremdwörterbuch (Auflage 1982) heißt es aber das Semaphor und nur in Österreich der Semaphor.
Was mich aber nicht anficht. Denn ich kenne den Begriff (auch und insbesondere aus der Informatik) mit e am Ende.
Zwar lautet Träger im Griechischen normalerweise phoros (maskulinum), aber es gibt kein Hindernis, davon das femininum (phorä oder sowas) zu bilden. Davon abgesehen habe ich es (auch im Griechisch-Unterricht, soweit ich mich daran überhaupt noch erinnern kann) so gelernt und mein Sprachgefühl sagt mir, daß alle Begriffe, die aus dem Griechischen und Lateinischen abgeleitet sind und auf kurzes e enden, feminin sind (Antike, Amphore, Tragödie,…), zumal auch die griechischen Namen, die auf kurze e endeten, Frauennamen waren (Athene, Euridike, …)
Ich bleibe bei die Semaphore.
Es heißt ja auch der Schneck und die Schnecke.
Sowas kommt dabei raus, wenn man ein Tausend-Knöpfe-Interface hat:
Die Möglichkeiten irgendwas falsch zu machen sind unerschöpflich.
Leider glauben viele Leute, man können ein System dadurch verbessern, indem man weitere Einstellmöglichkeiten hinzufügt; es wird dadurch aber nur noch schlimmer.
Auch von mir einen herzlichen Glückwunsch und alles Gute zum Geburtstag 🙂
Sehr interessanter Beitrag … vll sollte ich den an die IT weiterleiten … xD
Oha, das ist mal ne schräge nummer gewesen mit dem webserver, hatte mich gestern nach dem von den laien artikel auch arg gewundert das die seite auf einmal weg war. Danke btw für die info, das muss mensch schon wissen 😉
Dennoch, Happy Birthday nachträglich und weiter so, hast ein echt tolles blog hier 😉
Grüße, Hacky
@ carsten
immerhin wurde er nicht geBKAed oder von-der-line genommen^^ 😛
ich hoffe wir bekommen trotz des problems mit dem RSS-feed wieder eine verlinkung zu forschungsmafia.de (und vllt auch mal von dort zurück auf danisch.de) wäre sehr nett 🙂
und weiter so!!!111
Wohl wegen besagten Problems nicht mehr mit WordPress sondern erst, wenn das neue Blog fertig ist. Das wird aber voraussichtlich noch ein paar Monate dauern.
Und das alles ohne funktionale Programmierung. *scnr*
M.E. nach liegt der Hund eben beim prefork MPM begraben. denn der worker MPM hat zwar den Nachteil, dass das komfortable mod_php5 nicht verwendet werden kann, aber dafür können die Prozesse verschiedener Webseiten als verschiedene Nutzer laufen – was sowohl Sicherheit als auch Stabilität enorm erhöht.
Aber ich verstehen schon, dass viele große Projekte einfach nicht darauf ausgelegt sind, in so einer nicht-dem-Monopol-entsprechenden Konfiguration zu laufen. Bei einigen meiner Web-Anwendungen (roundcube glaube ich z.B.) musste ich auch Hand anlegen um sie mit PHP per CGI zum Laufen zu kriegen.
Herzlichen Glückwunsch auch von mir!
Kam durch Netzpolitik auf deinen Blog. Hab ich kurzerhand gleich mal gelinkt um dein Problem dass du hier beschreibst öfters auftreten zu lassen 🙂 (Natürlich nur damit du es eher debuggen kannst).
Spaß beiseite … schöner Blog und interessante Ansichten zu verschiedenen Themen. Glückwunsch und weiter so!
Werter Herr Danisch. Es gibt zwei Sachen, die mir an Ihnen (und Ihrem Blog) nicht gefallen.
Zum Einen entschuldigen Sie sich für eine Panne, die garantiert von Ihnen selbst insziniert wurde, um die Spannung auf Ihre Artikel künstlich hochzuhalten und zu verlängern. Das ist Betrug an den Tausenden Lesern Ihres Blogs.
Und zum Anderen finde ich nirgendwo einen Link auf Ihren Seiten darüber, wie man Sie in den Bundestag wählen kann und wann Sie endlich Ursula v.d.L ersetzen (oder jemand anderen Inkompetenten, da lasse ich Ihnen die freie Auswahl aus 600+X).
Mit freundlichen Grüßen, ein ab jetzt regelmäßig wiederkehrender Neuleser.
Bei diesem Kommentar hab ich ne Weile gebraucht um mir zu überlegen, ob’s jetzt ne Frechheit oder ein Kompliment sein soll.
Die Panne habe ich aber garantiert nicht inszeniert. Sowas ist erstens nicht mein Stil, zweitens würde es in ganz grober Weise gegen meine Verpflichtungen als Admin und Vorstandsmitglied des Vereins verstoßen, denn das wäre Sabotage und würde massiv die Funktion der anderen (virtuellen) Webserver auf der Maschine beeinträchtigen, die für die anderen Mitglieder (und damit meine Freunde) laufen. Außerdem würde es in wüster Weise gegen meine Berufsehre und meine Tätigkeit verstoßen. Außerdem hat es mich ein Abendessen mit Freunden gekostet.
Davon ganz abgesehen wäre es eine schlechte Idee, denn sowas hebt im Web überhaupt nicht die Spannung, sondern vergrault Leser. Gerade bei solchen Artikeln, auf die Leute aufgrund von Links spontan draufklicken, kommt es ganz massiv darauf an, daß die Informationen auch verfügbar sein, weil das Interesse sehr schnell wieder abfällt. Ich würde mir damit ins eigene Fleisch schneiden, zumal das natürlich auch beruflich nicht so super toll aussieht.
Außerdem: Wie hätte ich das denn inszenieren sollen? Ich wußte ja vorher nicht, daß ich verlinkt werde und daß das soviele Leute nach 2 Jahren noch interessiert. Ich habe auch an der Serverkonfiguration in den letzten Wochen überhaupt nichts verändert. Ich habe zudem ein Alibi.
Nein, das war nicht inszeniert.
Es tut mir leid, wenn ich Sie durch meinen Kommentar verunsichert haben sollte, aber es war nicht Satire oder schwarzer Humor, sondern blankes Entsetzen über unsere Parlament-Arier, die mich zum Schreiben bewegten. Dass mir nicht die Haare zu Berge stehen bei dieser geballten Inkompetenz verdanke ich nur meinem Erbgut und dem damit einhergehenden frühzeitigen Haarausfall. Leider besitze ich keinen Resetknopf, denn vieles, was ich hier gelesen habe, würde ich gern vergessen, um unbeschwerter leben zu können. Manchmal mach Wissen einfach keinen Spass.
Hallo, wollte noch was zu gestrigen Artikel schreiben, der ist dir wirklich gelungen.
Zu:
Wie die deutsche Internet-Kinderpornosperre zustande kam – und zugrunde ging
Dies alles was du beschrieben hast und wie du es gemacht hast vorallem die Nachvollziehbaren Verknüpfungen müsste man meiner Meinung nach auf das ganze bestehende, Angewandte System beziehen, der Artikel hätte also unter einer beliebigen Überschrift zur System relevanten Themen und aber auch zu Moralisch Ansprechenden Themen sein ziel nicht verfehlt, das zeigt und zeugt von einem GESUNDEN MENSCHENVERSTAND; Danke vielmals weiter so und niemals Nachlassen bzw. Aufgeben, Sehr GUT…. Es sollte auch Voice Blogs geben um sich zu unterhalten, denn meist liest man ein Artikel und während dessen könnte man auch zwischen funken, da der Gedanke auf diese Weise nicht mehr wieder kommt – ( also der Genanke beim ersten mal wo man es hört und sofort den richtigen Durchblick hat, ohne vorher andere Meinungen /Kommentare gehört zu haben ) – wenn man es sich bis süpäter also zum Ende verkneift….
Wenn ich das hier alles so lese bleibt mir nur eine Frage: Kennst du Caching?
Wenn du das vernünftig machst, und die WordPress-Grütze nicht sehenden Auges ins offene Messer wirfst, sparst du dir beim nächsten Mal das Lamentieren.
Ich darf das sagen, weil ich schon ein paar Fefe-Verlinkungen überlebt habe.
Freilich kenne ich das. Gab es da nicht gerade kürzlich Sicherheitsprobleme?
Meine Kritik an WordPress bzeieht sich auch darauf, daß das Ding eine gemessen an seiner Funktion schon viel zu hohe und – aufgrund des krautigen Programmierstils – nicht mehr zu beherrschende Komplexität aufweist. Und daß mir PHP gewaltig auf den Wecker geht. Beide Punkte werde ich nicht verbessern, indem ich noch eine Komplexitätsschicht oben drauf packe.
Außerdem hätte das bei beiden Problemen nichts geholfen, weil es weder etwas daran geändert hätte, daß WordPress einen neuen RSS-Feed holen muß, noch daß der Apache-Server nach Fertigstellung der Seite wegen KeepAlive gewartet hätte. Der Cache beschleunigt etwas, was hier nicht das Problem war. Der Prozessor war nicht überlastet, Rechenleistung war genug da.
Wie gesagt bin ich gerade in der Planung eines neuen Blogs, und das wird dann noch weiter gehen als Caching. Es wird ein von außen nicht sichtbares Redaktionssystem geben, das einfach statische HTML-Webseiten ausspuckt. Ganz ordinäre Webseiten ohne jedes PHP usw., die möglichst viel von einem Blog mit einigen Mulitmedia-Funktionen und auch Wiki-Funktionen abbildet, aber eben mit statischen Webseiten. Also quasi einen voll gefüllten Cache-Inhalt ausspuckt.
Kinderporno – noch ein Nachtrag
Die Fokussierung von Andre Meister auf Ziercke, BKA, halte ich für falsch. Im Internet staatliche Zensur mit Sperren einzuführen, wabert schon lange durch die CDU. Der vorbestrafte Manfred Kanther wollte 1998 unbedingt das ganze Internet nach Bilder durchsuchen und mit verbotenen vergleichen, die er schon hatte. Die Fundstellen wollte er dann sperren.
“INTERNET
http://www.sündenbock
Montag, 27.07.1998, 00:00 · von Simon Kaatz
Ist das Netz ein Kinderporno-Highway? Oder liefert die angeheizte Debatte nur Munition für Datenkontrolleure?
…
Nach einem Geheimpapier aus dem von Günter Rexrodt (FDP) geleiteten Bundeswirtschaftsministerium soll in einer novellierten Verordnung für die Telekommunikation – kurz TKÜV – auch der Lauschangriff aufs Internet möglich sein. Auszug aus dem Referentenentwurf: „Die zu überwachende Telekommunikation kann die im Internet verfügbaren Dienste (z. B. www, FTP, E-Mail, Telnet, Telefonie) enthalten.“ Kurt Schelter (CSU), Staatssekretär im Bundesinnenministerium, sprach vorige Woche von einem „legalen Abhören“ beim Verdacht schwerer Straftaten.
Innenminister Manfred Kanther (CDU) reicht auch dieses neue Instrumentarium nicht. Seine Beamten lassen derzeit an einer Suchsoftware basteln, die das Internet automatisch nach verbotenen Inhalten durchforstet. Wie das funktionieren soll, wenn 2500 Internet-Surfer gleichzeitig in Mega-Chaträumen wie „Metropolis“ plaudern, bleibt ein Bonner Geheimnis. Außerdem will Kanther eine „Ausweispflicht für Nutzer von Online-Diensten“, so sein Staatssekretär, einführen.”
http://www.focus.de/kultur/medien/internet-www-suendenbock_aid_173155.html
Damit ist aber das policy setting von Meister nicht umfassend sondern punktuell untersucht worden. Seit Jahrzehnten sachkundig ist da zum Beispiel der ehemalige Bundestagsabgeordnete Tauss, der offenbar von Meister weder befragt noch recherchiert wurde. Ziercke war damals nicht im BKA sondern in Schleswig-Holstein. So geheim ist das alles nicht, das man das nicht besser hätte recherchieren können. Zu Zandvoort an Zee könnte ich auch tonnenweise Geschichten erzählen und Fehlverhalten von Polizeien mehrerer Bundesländer. Kinderpornografie ist halt eine schwierige Geschichte.
Das Zugangserschwerungsgesetz ist übrigens immer noch in Kraft und Ziercke, SPD, vom BKA missachtet das Gesetz.
Is richtig. Aber eigentlich hatte ich das nicht so vorgehabt, daß ich die Kommentarfunktion zum Kinderpornosperrenartikel dicht mache und es dann hier zu einem anderen Artikel damit weitergeht.
Nur ueberflogen bis der Feed als (eines der?) Probleme dargestellt wurde.
Wwarum eigentlich mehrere VMs? Wenn die sogar noch weitestgehend die selbe Software laufen haben? Isolation kann Komplexitaet verringern, aber zwei Blogs auf einem Apache hosten ist ja nun nicht so kompliziert, dass man da mit zwei VMs was gewinnen wuerde.
Ich versuche eher, zwischen “viel von extern benutzt” und “eigene services, teilweise mit accounts von/bei kumpels und privaten daten” zu trennen.
Wenn man mal Abstand nimmt, ist dieses manuelle Tuning der Apache Threads/Prozesse ja auch lachhaft. Der Server selbst sollte so eine einfache Regel schneller und besser als du berechnen koennen, und vor allem auch zur Laufzeit reagieren: Wenn 100 threads auf eine Antwort warten, macht es vermutlich keinen Sinn, weitere 100 threads fuer die selbe Anfrage zu starten. Oder?
Das hast Du falsch verstanden.
Eine VM für Webserver, eine für Mail usw. Ein Apache hostet über 100 virtuelle Webserver.
Quatsch.
Lasst Euch bitte nicht durch Hadmut’s Ausführungen ins Boxhorn
jagen!
Schuld am Absturz sind nur Fefe, das nichtexistierende
Bielefeld ( 😉 ) und eine gewisse Doktorarbeit,
die ich, nachdem mir beim Lesen derselben kalte Schauer
über den Rücken liefen, mal einer gewissen hanna ins
Krankenhaus zum “Mitlesen” nehemen werde.
B.
Bielefeld ist eine hervorragende Ausrede. Aber Fefe würde ich da jetzt keine Schuld geben.
Hadmut meinte:
> Aber Fefe würde ich da jetzt keine Schuld geben.
Recht hast Du, aber dann bleibt nur eine Erklärung:
Fefe arbeitet auf Anweisung ( repeat Anweisung )
eines Höheren Herrn. ;-o
B.
Nein. Du hast einfach das erste Gebot der Computer- und Internet-Technik übersehen: Shit happens.
Es ist schon schauerlich, was selbst mit dokumentierter quelloffener Software alles schiefgehen kann. Richtig gruslig wird es, wenn irgendwelcher zugenagelter Kram in die Knie geht (gerade in der Zeitung gelesen: in .no ist eine komplette Krankenhaus-EDV stehengeblieben, und die wissen noch nicht mal, wie sie nach der Ursache forschen sollen, weil alles Binary-only und geheim usw. ist).
Dann mal noch alles Gute, und hoffen wir auf die Griechen (wird wohl bald chinesische Kolonie werden, zumindest wenn ich in China was zu sagen hätte).
Oh, den Quelltext habe ich hier zur Fehlersuche auch nicht verwendet, sondern nur strace, tcpdump, einen Testclient und ein bisschen Grips, das war also praktisch das gleiche wie bei binary-only.
In anderen Fällen habe ich allerdings auch schon oft auf den Quelltext zugegriffen, das ist schon wichtig.
@Hadmut: Verstehe ich, mache ich auch nur bei Bedarf (ich musste mal KDE-Quellen lesen, weil das damals der absolut einzige Punkt war, wo man über die Existenz und Startweise (binär und nichtkonfigurierbar aus einem C++-Dingens des KDE heraus) des kwrited erfahren konnte [0]), aber normalerweise tendiert Opensource-SW dazu, auch lesbare Konfigurationsfiles und Anleitungen zu haben. Der Kauf-Binär-Kram, dem ich begegne, hat “Anleitungen” der Art “Klicken Sie hier, klicken Sie da. Herzlichen Glückwunsch, Sie sind fertig. Wenn Sie Probleme haben, kontaktieren Sie unsere Warteschleife unter 0900/1234567 oder den Support unter devnull@hersteller.com.”. Ein Kollege muss z.B. dauernd beim Kunden in irgendwelchen undokumentierten (mittels cygwin-find ermittelten) XML-configs herumeditieren, weil das dazu bestimmte GUI kaputt ist.
[0] stimmt nicht ganz – ich fand danach noch einen Eintrag in einem Entwicklerforum, wo jemand gestand, das Teil programmiert und den Aufruf eingebaut zu haben.
PS: Beim Absenden kam ein Fehler, dass der Server JS und Kekse will, nach Reload war der Kommentar aber nicht da. 2. Versuch.
Hadmut meinte:
> Shit happens.
Ooooch … 🙁
Was? doch kein cyberterroristischer Angriff?
Keine Wikipedia-Cache Kompromittierung? 😉
da haben die Herren ja ganz schön nachgelassen … 😉
B.
nix für ungut … 🙂
Na dann doch wenigstens noch herzlichen Glückwunsch zum Geburtstag … nachträglich.