4.13.x: Fehler 503 im Frontend

Druckbare Version

16.09.2022, 11:31
Dr. Jo

4.13.x: Fehler 503 im Frontend

Hallo zusammen,

ich habe hier aktuell mindestens drei Contao 4.13.x-Installationen mit dem gleichen Phänomen:

- nach einiger Zeit Inaktivität im Frontend (Zeit kann ich nicht genau beziffern, ca. > 1 h) ist das Frontend nicht mehr erreichbar, sondern gibt nur noch 503 aus (servergeneriert)
- Backend und Contao Manager sind weiterhin erreichbar
- Cache-Bereinigung über die Systemwartung (Contao Backend) bringt keine Abhilfe, sondern nur der Neuaufbau im Manager
- alle Installationen beim gleichen Hoster, aber auf unterschiedlichen Servern, PHP 7.4.30

Das Contao-Log vermeldet nichts, und das Server-Logfile hilft leider auch nicht weiter, da steht beim Aufruf dann statt 200 halt einfach 503 =>

Code:

193.254.21.101 - DEVEL [16/Sep/2022:11:55:31 +0200] "GET / HTTP/1.1" 503 719 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.126 Safari/537.36"

Bei einer der Seiten habe ich mir temporär mit einem Uptime-Monitoring beholfen - einmal in der Stunde anpingen hilft. Aber das kanns ja nicht sein.

Irgendeine Idee, in welche Richtung ich weiter suchen sollte? Eher Server? Contao? ... meinen "Hoster der Herzen" habe ich noch nicht kontaktiert, wollte erst einmal schauen, ob das hier im Forum jemand kennt ...

Bin dankbar für jeden Hinweis!
16.09.2022, 11:46
tab

Ich würde erst mal in Richtung Server suchen. 503er (Service unavailable) gehört zu den Serverfehlern, wie alle 5xx. Deutet auf Kapazitätsprobleme des Servers hin (nicht performant, zu stark überbucht, überlastet). Dass es mit regelmäßigen Zugriffen zu verhindern ist, könnte darauf hindeuten, dass dein Contao aus dem OPCache rausfliegt, weil der begrenzt ist und andere Seiten, die den selben Cache nutzen, aufgerufen werden und dadurch ihre PHP-Skripte in den Cache ablegen und dafür "alte" Cache-Einträge (deine) rausfliegen. Durch den regelmäßigen Aufruf kommen deine dann auch wieder in den OPCache. Ohne OPCache ist die Ausführung eventuell so langsam, dass es am Ende den 503 Fehler gibt.
16.09.2022, 13:55
Spooky

503 Kann aber auch der reguläre Wartungsmodus von Contao sein.
16.09.2022, 14:14
tab

Ja, das stimmt, 503 kann auch der/ein Wartungsmodus sein, dann ist der Service absichtlich "not available". Aber dann sollte es doch nichts helfen, die Seite regelmäßig aufzurufen?!? Das Frontend sollte man dann eigentlich gar nicht zu sehen bekommen. Ansonsten einfach den Wartungsmodus ausschalten :D.
16.09.2022, 15:07
Dr. Jo

Vielen Dank für die Hinweise, dann werde ich mich mal an den (sehr guten) Support meines Hosters wenden. Der Contao-Wartungsmodus ist es definitiv nicht, da ist die Frontend-Ausgabe anders, habe ich auch noch per Konsole gecheckt und kann das ausschließen.
16.09.2022, 15:29
Spooky

Wie sieht der Response (inkl. Body) denn genau aus?
16.09.2022, 16:24
Dr. Jo

Das ist das, was vom Hoster bzw. dessen Server kommt, eine schöne, große 503: :cool:

HTML-Code:

<!DOCTYPE html> <html style="height:100%"> <head> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" /> <title> 503 Service Unavailable </title></head> <body style="color: #444; margin:0;font: normal 14px/20px Arial, Helvetica, sans-serif; height:100%; background-color: #fff;"> <div style="height:auto; min-height:100%; "> <div style="text-align: center; width:800px; margin-left: -400px; position:absolute; top: 30%; left:50%;"> <h1 style="margin:0; font-size:150px; line-height:150px; font-weight:bold;">503</h1> <h2 style="margin-top:20px;font-size: 30px;">Service Unavailable </h2> <p>The server is temporarily busy, try again later!</p> </div></div></body></html>

Was mich eben nur wundert, ist, dass Backend und Manager problemlos erreichbar sind, aber das Frontend nicht ...
24.10.2022, 20:03
ChrisT

Ich habe gerade zwei Installationen, die ausser dem Contao Manager 1.6.1 nicht viel gemeinsam haben (Contao 4.9.23/4.9.34). Nach einiger Zeit, die ich noch nicht genau zu messen versucht habe, zeigen beide Error 503. Das Löschen des Caches per Contao Manager bringt sie wieder zum Laufen.

Bei einer der beiden war ich ein paar Tage lang täglich am Werkeln – solange ich regelmässig Zugriffe tätigte, lief sie reibungslos.

Weiss mittlerweile jemand etwas Genaueres?
25.10.2022, 17:56
ChrisT

Heute Nachmittag habe ich die ältere Version auf 4.9.35 aktualisiert, das Auftauchen des 503-Errors ist unverändert. Nun habe ich ein Monitoring eingerichtet, das verraten wird, nach welcher Zeit die Seite ausfällt.
26.10.2022, 07:02
Dr. Jo

Hallo Chris,

mein Zwischenfazit, auch nach Kontakt und Intervention vom Hoster: Bei mir trat das Problem nur mit PHP 7.4 auf, nicht mehr mit PHP 8. Da sich das bei den Installationen, die bei mir von dem Problem betroffen waren, bewerkstelligen ließ, habe ich das gemacht und es dabei bewenden lassen mangels Zeit. Von Hosting-Seite konnten jedenfalls (leider) keine weiteren Erkenntnisse beigesteuert werden aus Logfiles o.ä. Was mich nach wie vor etwas stutzig macht, ist, dass das bei doch nur bei einem Bruchteil der Installationen aufgetreten ist (beim gleichen Hoster) - evtl. doch ein Zusammenspiel mit bestimmten Erweiterungen?
26.10.2022, 08:24
ChrisT

Vielen Dank für dein Feedback! Und das ohne konkreten Hinweis auf eine Lösung, sondern offenbar nur aus Betroffenheit und Nettigkeit – was ich umso mehr zu schätzen weisse, weil es zur Seltenheit geworden ist.

Das Monitoring scheint Wunder zu bewirken: Offenbar schubst es die Website im 5-Minuten-Takt an, was zu keinen weiteren Ausfällen mehr geführt hat. Gehen wir mal davon aus, dass wir nicht die einzigen sind oder bleiben, und deponieren hier einfach Workarounds und Ausschlusskriterien.

– Contao Manager 1.6.1: Andere Websites funktionieren einwandfrei
– CMS-Version schliesse ich aus (ich habe zahlreiche 4.9 am Laufen, keine anderen Installationen haben das Problem)
– Eclipse Theme: Ich habe, zwei andere Websites mit dem Theme, die anderen beiden laufen (Eclipse 9 und X4)
– Hosting Provider: Die beiden Websites laufen bei unterschiedlichen Anbietern. Bei beiden Anbietern machen zahlreiche andere Websites keine Probleme.
– Contao-Erweiterungen: Bei beiden installiert sind lediglich Easy Favicon und Shortlink, beide verwende ich bei mehreren anderen Sites, die einwandfrei laufen

Offen bleiben:
– PHP-Version: Da ich teilweise noch Eclipse 9 verwende, kann ich nicht auf PHP 8 wechseln

Natürlich kann es sein, dass die Ursache für den Fehler nicht bei beiden Seiten die gleiche ist. Aber «anstupsen» hilft offenbar.

Mehr kann ich aus technischer Sicht nicht sagen. Falls es weitere Fälle mit diesem Problem gibt, stehe ich gerne für Tests zur Verfügung.
26.10.2022, 09:01
tab

Ich verweise noch mal auf meinen früheren Beitrag. Wirklich neu an diesem Verhalten ist eigentlich nur, dass es hier jetzt bis zu einem (Server-) Fehler 503 eskaliert. Es gibt zu dem Thema auch ältere Beiträge von Contao-Entwicklern. Wenn im shared Hosting zusätzlich open_basedir aktiv ist (was automatisch den RealPath Cache deaktiviert) und eventuell die I/O Performance suboptimal ist, so dass die aus dem OPCache geflogenen PHP-Skripte eben länger zum Laden brauchen, verstärkt das eben den Effekt. Ebenso wie natürlich auch eine hohe Serverlast. Ohne das hier den Webhostern unterstellen zu wollen, könnten manche eben doch angesichts der stark gestiegenen Kosten (Energiepreise ...) versucht sein, die Server im Shared Webhosting stärker zu überbuchen als früher, also mehr Kunden auf den selben Server oder die selbe Cloud zu packen als früher.

Mit der Contao-Manager Version sollte es eigentlich nichts zu tun haben, da der ja überhaupt nichts macht, solange er nicht aufgerufen wird. Und das wird er im normalen Betrieb nicht, man kann ihn nach erfolgter Installation problemlos wieder löschen und nur bei Bedarf (Update, Erweiterungen installieren) wieder installieren. Was ich hier explizit nicht empfehlen will, sondern nur erwähne um zu zeigen, dass er keinen Einfluss auf die Live-Performance einer Installation hat.
26.10.2022, 14:53
Dr. Jo

@ChrisT vielen Dank für die freundlichen Worte :) - das mit dem Monitoring hatte ich ja schon im Eingangspost geschrieben, aber irgendwie kanns das IMHO ja nicht sein, ein bloßer Workaround

@tab als (shared hosting-) Kunde habe ich in einem solchen Fall dann natürlich das Problem, dass ich kaum Möglichkeiten der Analyse habe und mich darauf verlassen muss, dass serverseitig alles läuft wie versprochen.
26.10.2022, 15:27
tab

Workaround? Mag sein. Dann aber ein Workaround um ein Serverproblem. Wobei das natürlich auch wieder jeder anders sehen wird. Aus Contao-Sicht könnte man sagen, der Webserver hat nicht die benötigte Performance. Aus Hostersicht dagegen, Contao braucht zuviele Ressourcen. Es gbt halt immer (mindestens) zwei Seiten. Wer ist denn der "Hoster der Herzen"? Vielleicht melden sich dann noch ein paar weitere Leidende hier im Thread. ;)

Wie geschrieben, das Phänomen wurde bereits bei Contao 4.4 untersucht von den Core-Entwicklern. Lediglich der Serverfehler 503 ist jetzt neu, passt aber ins Schema, weil er eine Überlastung anzeigt. Damals war es "nur" eine sehr lange Zeit, bis die Seite ausgeliefert war. Jedenfalls kann der Server die Anfrage in dem Moment nicht bedienen. Aber andere Idee, den "Command-Scheduler" habt ihr doch nicht am Laufen, sondern einen richtigen Cronjob? Ansonsten könnte es eventuell sein, dass der Contao "Poor Man's Cron", der natürlich bei einer ersten Aktion nach längerer Zeit in der Regel aufgerufen wird, aus welchem Grund auch immer das Problem verursacht. Frage an jemand, der sich damit auskennt: Welche stündlichen Aufgaben müssen denn in Contao 4.13 abgearbeitet werden? Andererseits wird das ja - soweit ich weiss - erst abgearbeitet, nachdem die Seite bereits ausgeliefert ist.

Jedenfalls habe ich bisher mit Contao 4.13 noch keinen Fehler 503 gesehen. Muss ich nochmal bei netcup testen, da war damals der Effekt besonders krass. Ladezeiten über 20 Sekunden. Aber auch da hat der Workaround damals geholfen, auch wenn der "Schubser" nur der ganz normale (echte) Contao-Cronjob war, der eben regelmäßig ausgeführt wird und nicht nur nach einem Seitenaufruf im Frontend.

Edit: Habe mir gerade nochmal den alten Issue auf Github durchgelesen. Danach bin ich mir nicht mehr sicher, ob das hier die selbe Ursache hat. Damals war wohl doch auch das Backend betroffen und nicht nur das Frontend, was ja hier anders zu sein scheint. Aber die "Ansichtssache" aus meinem ersten Absatz oben wird in dem Issue jedenfalls bestätigt :D.