Hallo Admins
Da gibt es viele Spiele-Themen die einen 500er erzeugen. Ist die Datenbank vielleicht zerschossen oder der Server am abrauchen?
Druckbare Version
Hallo Admins
Da gibt es viele Spiele-Themen die einen 500er erzeugen. Ist die Datenbank vielleicht zerschossen oder der Server am abrauchen?
link?
Zum Beispiel das ultimative SPAM-Wörterspiel
Ich sehe zwar, das andere inzwischen was gepostet haben, aber bei mir kommt wirklich das:
Anhang 17539
Ich habe schon andere Browser probiert; immer das selbe. Es kam plötzlich, ich war da vorher auch schon drin.
Stelle sicher dass du eine Direktverbindung zum Server hast.
Das nutzen von Proxy, Anonymizern (z.B. ToR, Onion, VPN, ...) usw. kann zu solchen Problemen führen.
Ansonsten ist unsere Software jene eines ehemaligen Marktführers.
Die WBC basiert auf vBulletin 4 für welches der Hersteller jeglichen Support eingestellt hat.
Dementsprechend wenig anspruchsvoll sind die Anforderungen an Browser.
Da tausende aktive Nutzer, und nur Du von diesem Problem berichtest - muss ich davon ausgehen dass DEIN Setting nen "hau" hat.
Ein Guter Anfang ist aktuellen Chrome, Edge oder Firefox zu nutzen.
Gegebenenfalls die gespeicherten Cookies der WBC löschen.
Das löschen der temporären Internetdaten sollte sich ja von selbst verstehen ;)
- Kein Proxy
- Kein VPN
- Alle getesteten Browser (Chrome, Firefox und Chromium) up-to-date
- Cookies und Site-spezifische Daten gelöscht.
Habt ihr mal einen Scan auf der DB gemacht? Gibt es einen Konsistenz-Check in der BB-Software?
Da hat wohl der Zoll die Sache mit der Netzneutralität nicht so richtig verstanden ? :P
Das was, wie und wo wir diese Site ins Netz bringen kann man im Forum nachlesen
ich sag nur so viel... viele IT´ler würden für solch ein Setting töten
Uff, das ist mir jetzt zu abstrakt. Kannst du das mal übersetzen?
aktuell gerade über 300 user online...
heute 523 registrierte eingeloggt gewesen
die letzten 30 tage 1748 unterschiedliche logins...
täglich mehrere tausend unregistrierte leser
und EINER davon hat probleme...
e500 (ist eine sammelfehlermeldung wo andere nicht passen) heisst die anfrage kann so wie angefragt nicht behandelt/abgearbeitet werden
da bräuchte ich schon nen screenshot wo browser komplett mit adressleiste, taskbar mit datum und uhrzeit... um genau diese abfrage im log heraussuchen zu können - sofern die überhaupt vom webserver kommt
hier sammeln sich jeden tag allein für diese website weit über 100k logeinträge zusammen - die werden aber nicht lang vorgehalten - datensparsamkeit und so...
bevor man ratschläge gibt wie db-scan, konsistenz-check usw gibt... sollte man sich mal schlau machen um was es sich handelt, wie es betrieben wird usw...
wer mit solchen sachen um sich wirft sollte mit bare metal, galera, tier 4 datacenter, vix2, interxion / digital realty vie-1 was anfangen können
die forumskiste ist ein dual-multicore-xeon mit mehr ram als manche harddisk haben, m.2-raid, und einer anbindung bei welchen nerds schon beim lesen ein 1/8 abgeht
über 95% der anfragen werden vom cache weg ausgeliefert
ja, das ist wie mit wasserstoffbomben auf obstfliegen schiessen... aber das flutscht :D
warum das so ist kann man im forum nachlesen - die suche ist dein freund
anhand deiner ip sehe ich das es sich mit großer wahrscheinlchkeit um einen cable-account handelt... ob docsis, cgnat, 6to4, cdn, usw da mit reinspielen kann ich von hier aus nicht beurteilen
ob du filterscripte, ne art security-suite nutzt kann ich mangels einsatzbereiter glaskugel auch nicht sagen...
alle browser-addons abschalten, dem sicherheitspaket (antivirus, internetsecurity, endpointprotection, wwi..) sagen es soll mal paar minuten die füsse still halten und sich nicht einmischen
temporäre internetdaten löschen, cookies entfernen, browser starten und neu laden erzwingen
wenn dann immer noch probleme, auf anderem gerät, idealerweise auch mit anderem internet-provider prüfen
Ich programmiere so Zeugs wie dieses seit 35 Jahren. Und nicht nur mit PHP-Skripten, mit richten Programmiersprachen wie C++ und Python. Darum kann ich schon mit Sachen wie DB-Scan etc um mich werfen.
Und zum 500er. Das ist nicht einfach eine "Sammelfehlermeldung". Der Code besagt spezifisch, dass ein interner Bug aufgetreten ist, eine interne Situation, mit der die Serversoftware nicht mehr klar kommt. Ich weiss das, weil ich oft entscheiden muss, ob der Fehler eine 4xx-Klasse ist, oder eine 5xx. Das bedeutet, dass es am Server liegt und nicht am Browser.
Allerdings kann ich Entwarnung geben, es scheint wieder zu funktionieren.
Schön dass du die Seite wieder laden kannst...
vielleicht aber doch mal das Wissen um Statuscodes auffrischen...
https://developer.mozilla.org/ ist da eine gute Anlaufstelle
https://developer.mozilla.org/en-US/...TTP/Status/500
aber auch die RFC 9110 spricht eine klare Sprache
https://httpwg.org/specs/rfc9110.html#status.5xx
https://www.rfc-editor.org/rfc/rfc9110#status.5xx
Ein Programmierer kann sich NIEMALS aussuchen wohin er einen Fehler zuordnet - außer er ist in der IETF welche diese "Internet Standards" definiert und es schafft die tausenden Mitarbeitenden zu überzeugen dass das so sein sollte.
---
Ich bin kein Programmierer; ich bin einer von den Jungs die dafür sorgen dass Programmierer Spielzeug haben
Statuscodes werden vom Daemon welcher die Services bereitstellt definiert und auch von Daemon (in jenem Falle httpd) ausgegeben - nicht von Programmcode der Website
Es hat niemand darauf Einfluss welchen Statuscode der Deamon ausgibt, außer diejenigen welche den Deamon pflegen.
---
Zitat:
the hypertext transfer protocol (http) 500 internal server error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.this error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response.
Zitat:
the http status code “500 – internal server error” is one of the many 5.x.x. Http error codes (500, 502, 503, 504, etc.). Each of them specifies a different problem..the hosting server can’t determine the exact problem and display a more specific message. It responds with the error “500 internal server error” which means that it’s not clear what’s wrong.
Zitat:
http status codes provide information about whether an online request was successful, and if not, what the error is. But the error messages aren’t always clear. This is especially the case for the “500 internal server error.” this message indicates that an error has occurred during connection to the server and that the requested page cannot be accessed. However, it won’t tell you exactly why this is the case.
---Zitat:
http error 500 / internal server error ist ein »sammelbecken« für alle arten von serverfehlern und besagt nur, dass der server die vom client gestellte anfrage nicht erfüllen kann. Daher werden die angeforderten webseiteninhalte nicht angezeigt.
alles in allem fängt die fehlerbehebung IMMER gleich an.
im eigenen webbrowser den cache killen und die vorhandenen verwendeten cookies löschen
denn im regelfall (ausser beim ersten besuch) wird nur der dateninhalt ausgeliefert, layout, designelemente, usw. werden vom lokalen cache am eigenen computer/handy/tablet/mixer/... aus bereitgestellt
wenns im lokalen cache ein problem gibt, kann der browser mit übertragenem content natürlich nix anfangen
wenn tausende clients fehlerfrei arbeiten und einer ein problem hat, ist es zwar möglich dass genau dieser eine client auf einen hostseitigen fehler gestossen ist - aber eher unwarscheinlich
erst wenn dieser fehler mit anderen clientdevices reproduziert werden kann ist davon auszugehen dass ein hostseitiges problem vorliegt
der gemeldete fehler war zu keiner zeit mit einem anderem als deinem clientdevice reproduzierbar
ergo kein hostfehler
Ja, das ist leider etwas unglücklich ausgedrückt, bzw. falsch. Das muss ich dir etwas erklären.Zitat:
vielleicht aber doch mal das Wissen um Statuscodes auffrischen...
https://developer.mozilla.org/ ist da eine gute Anlaufstelle
https://developer.mozilla.org/en-US/...TTP/Status/500
aber auch die RFC 9110 spricht eine klare Sprache
https://httpwg.org/specs/rfc9110.html#status.5xx
https://www.rfc-editor.org/rfc/rfc9110#status.5xx
Der Umstand, dass eine Fehlerbedingung aufgetreten ist, ist ein sehr konkreter Umstand. Der Begriff catch-all besagt in diesem Zusammenhang lediglich, dass der Code selbst (500) nicht näher erläutert, was für ein Fehler aufgetreten ist (klar: ist ja auch immer derselbe Code). Eine Erklärung der Fehlerbedingung wird oft (aber leider nicht immer) in einem Begleittext beigefügt. Beispiel: Der Code kann in die Lage kommen, eine Zahl durch Null dividieren zu müssen, was je nach Interpretation "nicht erlaubt ist", oder aber unendlich ergibt, was ebenfalls nicht darstellbar bzw. zielführend ist. Als nächstes Beispiel kann der Code aber auch in die Lage kommen, aus einer Liste mit 6 Einträgen den 7. Eintrag holen zu müssen, was auch nicht ausführbar ist. Beide Fälle werden als 500er gemeldet, und das ist mit "catch-all" gemeint. Beiden Beispielen gemeinsam aber ist der Umstand, dass der Fehler im Server stattfindet. Der Server darf nicht auf falschen Input vom Browser mit einem 500er antworten. Dafür ist die 4xx-Klasse da.
Auch das ist nur bedingt richtig. In der Praxis kommt es vor, dass es nicht klar (=eruierbar) ist, ob jetzt wirklich ein unerwarteter Fehler vorliegt, oder ob das ganze nicht doch irgendwie mit dem Input zusammenhängt. Da muss man sich dann halt entscheiden, was man zurück gibt. Oft spielt die Software-Architektur eine Rolle in dieser Situation. Beispiel: Es soll Inhalt in die Seite eingefügt werden, der Bezug nimmt auf Input vom Request, der aber nicht gefunden wird. Nun könnte man wieder 500 zurückgeben, aber eben auch 404 (Not Found), weil etwas nicht gefunden wurde. Wenn der Code jetzt an einer Stelle steht, von der nicht mehr klar ist, ob es der Browser-Input war, der zum Nichtfinden des Inhalts geführt hat, was soll ich jetzt zurückgeben? Siehst du das Problem?Zitat:
Ein Programmierer kann sich NIEMALS aussuchen wohin er einen Fehler zuordnet - außer er ist in der IETF welche diese "Internet Standards" definiert und es schafft die tausenden Mitarbeitenden zu überzeugen dass das so sein sollte.
---
Ich weiss. 😉Zitat:
Ich bin kein Programmierer;
Damit meinst du die Hardware, right? Wir nehmen alles, so lange es schnell genug ist.Zitat:
ich bin einer von den Jungs die dafür sorgen dass Programmierer Spielzeug haben
Ähm, nein. Ein Daemon ist ein Programm, das ohne Control-Terminal bzw. ohne kontrollierenden Parent-Prozess läuft (in Unix und Derivaten wird technisch gesehen der Init Prozess (PID 1) zum Parent-Prozess gemacht) und hat gar nix mit Services, Fehlercodes und anderen funktionalen Details oder gar Server-Administration zu tun (es bist ja nicht du der entscheidet welcher HTTP-Code in welcher Situation zurückgegeben wird). Vielleicht meintest du einen Reverse-Proxy, wie .z.B. nginx, der sich ebenfalls von diesem Statuscode-Pool bedienen muss, z.B. wenn er den Request nicht zum Web-Server routen kann (in diesem Fall kommt ein 500er vom Proxy und nicht vom Web-Server). In jedem Falle aber besagt 500, dass der Fehler von der Server-Infrastruktur kommt. Alles andere wäre Falschinformation.Zitat:
Statuscodes werden vom Daemon welcher die Services bereitstellt definiert und auch von Daemon (in jenem Falle httpd) ausgegeben - nicht von Programmcode der Website
Es hat niemand darauf Einfluss welchen Statuscode der Deamon ausgibt, außer diejenigen welche den Deamon pflegen.
was ich ja auch gemacht habeZitat:
alles in allem fängt die fehlerbehebung IMMER gleich an.
im eigenen webbrowser den cache killen und die vorhandenen verwendeten cookies löschen
Stimmt so auch nicht. Der Browser behandelt für das Caching die ganze fertige, darstellbare Page als ein Element (ausser vielleicht eingefügte Frames).Zitat:
denn im regelfall (ausser beim ersten besuch) wird nur der dateninhalt ausgeliefert, layout, designelemente, usw. werden vom lokalen cache am eigenen computer/handy/tablet/mixer/... aus bereitgestellt
Software ist sehr komplex; effektiv das komplexeste was wir je zustande gebracht haben. Da kann es schon mal passieren, dass etwas nicht so abläuft wie erwartet. Glaub mir, ich weiss von was ich rede, ich mache das schon seit 35 Jahren. Ich hatte übrigens für kurze Zeit einen Zertifikatsfehler bei den betreffenden URLs. Und ich weiss, dass die SSL-Libraries und die mannigfaltigen Versionen davon immer eine Zitterpartie sind. Kann gut sein, dass es damit zusammen gehangen hat. Hoffen wir einfach mal, dass es das jetzt war.Zitat:
wenns im lokalen cache ein problem gibt, kann der browser mit übertragenem content natürlich nix anfangen
wenn tausende clients fehlerfrei arbeiten und einer ein problem hat, ist es zwar möglich dass genau dieser eine client auf einen hostseitigen fehler gestossen ist - aber eher unwarscheinlich
erst wenn dieser fehler mit anderen clientdevices reproduziert werden kann ist davon auszugehen dass ein hostseitiges problem vorliegt
der gemeldete fehler war zu keiner zeit mit einem anderem als deinem clientdevice reproduzierbar
ergo kein hostfehler
Wenn du nicht Programmierer bei der Apache Software Foundation bist welche Apache2 pflegt hast DU keinerlei Einfluss darauf welchen http-Statuscode unser Indianer hinausschiebt.
Die Jungs da halten sich an die RFC und da fährt die Eisenbahn drüber.
Du müsstest ein eigenes Backend entwickeln um nicht von apache, nginx, iss, gws, litespeed und co abhängig zu sein, dann könntest du auch bestimmen wann welcher Statuscode ausgegeben wird.
Ansonsten obliegt die Entscheidung dem zugrundeliegenden Paket
Was du als Frontender kannst ist zu beeinflussen was innerhalb deines Programmablaufes geschieht.
Wenn ich die ForenDB offline nehme bekommst du eine Seite, dass die Datenbank nicht erreichbar ist und du es später nochmal versuchen sollst.
Das ist ja kein Fehler des Webservers - das Programm hat ein Problem - nämlich keine DB-Verbindung - somit steht es dem Frontend frei zu entscheiden was am Browser angezeigt wird.
Klar könnte man auch eigene Fehlerseiten gestalten und zB bei e500 eine Seite bringen wo irgendwas draufsteht und der wahre Grund der Anzeige dieser Seite verborgen bleibt
Das hat aber allesamt nichts mit echtem http-status zu tun - intern kannst du ausgeben was du lustig bist das sind ja dann Laufzeit-Meldungen und keine http-Status
500 IST ein Catch-All, auch wenn du dir das noch so schönredest und nach deinen Wünschen interpretierst.
Der Server konnte keine Definition finden welche ausgesagt hätte das ist 502, 504, ... er muss aber etwas zurückgeben... also im Zweifel 500
Wäre ein DB-Problem vorhanden, betrifft dies NIEMALS den Webserver selbst, der agiert ja und dem ist ein anderer Service sowas von egal...
je nachdem wie das Frontend geschrieben wurde kommt ein Timeout oder wie zB. bei uns eine Meldung dass ein Problem mit der DB besteht... blablabla..
99/00 war ich in einer Entwicklung involviert und musste mich mit embperl und co rumschlagen
Nicht meine Welt
Hardware - ich bin doch kein Kistenschieber :P
Komm doch mal im Forum an, leb dich ein und sieh dich um dann erfährst du auch das eine oder andere
Apache2 läuft im Daemon-Mode
Als Daemon bezeichnet man unter Unix und Unix-artigen Systemen einen Prozess, der im Hintergrund abläuft und bestimmte Dienste zur Verfügung stellt. Benutzerinteraktionen finden hierbei nur auf indirektem Weg statt, zum Beispiel über Signale, Pipes und vor allem (Netzwerk-)Sockets.
Daemons können jedoch auch wie normale Prozesse in einer Shell durch einen Benutzer gestartet werden. Anschließend forken diese Prozesse und erstellen auf diese Weise einen Prozess, der mit der aufrufenden Shell nicht mehr verbunden ist und damit ein direkter Kindprozess des Hauptprozesses init wird.
Wenn "wir" (damit meine ich nicht nur diese Website) jede Website voll ausliefern würden...
dann wäre das www deutlich langsamer
alles was der Browser schon im Cache hat, wird nicht erneut ausgeliefert - wozu auch ?
nur weil der Enduser lediglich eine Anforderung im Browser eintippt oder anklickt, laufen da im Hintergrund je nach Seitenkomplexität zig bis hunderte requests ab.
die Zeiten sind schon sehr lange vorbei, wäre ja auch Schwachsinn bei jedem Aufruf zig Bilder, css usw neu zu übertragen nur weil sich 2 kB an Text verändert haben.
So wird nur die eigentliche Website übertragen und der Browser gleicht dann ab was er noch alles Nachladen muss um diese vollständig anzeigen zu können.
Sollten sich Bilder usw. geändert haben – deren Benennung aber nicht, werden solange die gechachten Inhalte angezeigt bis die maximale Cache-Gültigkeitsdauer erreicht wurde oder der Browser angewiesen wird Inhalte explizit neu zu laden.
Ich bin wie schon früher gesagt kein Programmierer… - was aber auch nicht Bedeutet ich wäre auf der Nudelsuppe dahergeschwommen.
wenn wer kommt und meint auf „meinen“ Hosts gäbe es ein Problem, dann sehe ich mir auch den Code an ob mir da etwaige Auffälligkeiten ins Auge springen.
Meist ist es ja so dass es in Fehlermeldungen heißt in Datei X an Stelle Y blabla…
also nachsehen was da steht, ob das nun ne Inkompatibilität zu einem zur Verfügung gestellten Paket ist, oder da einfach nur n Bezeichner/Begrenzer fehlt.
Beides zusammen sind die häufigsten Ursachen wenn etwas nicht so tut wie es sollte.
Jetzt wird mir langsam klar, wie du die Sache siehst.
Apache hat nur die Aufgabe, Requests zu interpretieren, und gemäss Datei-Typ entweder selbst zu handeln (bei statischen HTML-Seiten und Bild-Dateien) indem er sie unverändert zurückgibt oder sie aber einem CGI-Plugin übergibt, im vorliegenden Fall ein PHP-Interpreter. Je nachdem ob PHP als Shared Library oder als Fast CGI Prozess läuft wird eine Prozedur aufgerufen oder der Request wird via Sockets zum Prozess durchgeschleust.
Im Falle von statischen HTML Seiten liegt die ganze Funktionalität beim Apache. Ein 500er würde bedeuten, dass Apache selbst ein Problem (=Bug) hat, weil beim Ausgeben einer HTML-Datei kann wirklich nicht viel schief laufen. Aber es wird in dieser BB-Software wohl sehr wenige statische HTML-Seiten geben. Fast der gesamte statische Inhalt dürfte sich auf Bild-Dateien belaufen. Und damit ist die Geschichte mit Apache eigentlich schon beendet.
Der ganze Rest spielt sich da ab, was du als "Frontend" bezeichnest (heute wird nur noch mit JavaScript ergänztes HTML als Frontend bezeichnet; bei PHP ists halt ein bisschen komplizierter):
Genau das haben die, die die BB-Software geschrieben haben, gemacht. Und damit kommen wir zum PHP-Bereich (auf welche Art das Plugin läuft, weiss ich nicht, spielt auch keine Rolle).Zitat:
Was du als Frontender kannst ist zu beeinflussen was innerhalb deines Programmablaufes geschieht.
Wichtig ist nur, dass wenn der URL-Pfad auf .php endet, der Request von PHP gehandelt wird. Das läuft so ab, dass der PHP-Interpreter die Datei nimmt und sie praktisch wie eine HTML-Seite behandelt, nur dass im HTML-Code Sequenzen eingemischt sind, die etwa so aussehen:
(PHP-Code der HTML erzeugt)
?>
In dieser Sequenz wird dynamischer HTML-Code erzeugt, der gemäss Parametern im Request erstellt wird.
In diesem Code können nun Fehlerbedingungen vorkommen, die unvorgesehen sind. Fehlerbedingungen, die aus Parametern herrühren werden behandelt, in dem eine Fehlerseite oder auch nur ein Fehlertext mit einer Fehlermeldung, die der Benutzer verstehen kann, erzeugt wird. Wenn aber im Code etwas passiert, was nicht vorgesehen war, wird PHP einen 500er an Apache zurückgeben, der dann so aussieht wie gezeigt, wenn nicht eine schöne Error-Page dafür gemacht wurde. Das hat nichts mit "Server" oder "Daemon" oder Apache oder weiss was zu tun.
Also: hätte jeder Request einen 500er erzeugt, wäre tatsächlich ein Fehler auf Apache-Ebene vorgelegen. War aber nicht der Fall. Nur wenige Seiten haben diesen Fehler erzeugt, daher ist es naheliegend, dass auf PHP-Ebene (="Frontend") etwas unvorgesehenes schief lief. Und in diesem Fall wird 500 und nur 500 und mit Absicht zurückgegeben, weil das der korrekte Code ist ("Server error"). Ein bessere Erklärung wäre: "Sorry, we fucked up, we have a bug."
Es steht dem Code übrigens auch frei, irgendwelche 400er-Codes zu erzeugen, oft werden 404er benutzt um billig anzuzeigen, dass etwas (z.B. ein Element in der Datenbank) nicht gefunden wurde. Oder ein 400er, um falsche Parameter in der URL zu beweinen. Und nein, auch ein 400er ist nicht "catch all".
Und ja: die gesamte HTML-Seite ist eine Einheit. Das einzige was gecacht werden kann, sind die Bilder, weil die nicht Bestandteil des HTML-Texts sind (es sei denn, das Bild wird In-Line codiert). Der ganze HTML-Text kann leider nicht gecacht werden, weil der dynamisch ist. So ist das nun mal.
Übrigens: In modernen Container-basierten Umgebungen läuft kaum ein Server noch im Daemon-Mode, weil das Logging und der Server-Prozess selbst auf diese Weise schwer handhabbar sind. Logging wird auf stdout und stderr gemacht, wo es abfang- und umleitbar ist.