Probleme mit FastCGI, 500er Scriptfehler

**gregor** · 12.02.2018, 19:41

Ganz sporadisch treten im BE mit Contao 4.4.13 beim Anklicken von Menüpunkten 500er Fehler auf. Dabei ist es egal ob auf Systemwartung, Seitenlayouts, Benutzer, Artikel oder andere Punkte geklickt wird.

Die Serverlogs geben folgende Einträge wieder:

Code:

2018-02-12 15:49:18	xx.xxx.xx.xxx:50483	FastCGI: incomplete headers (0 bytes) received from server "/etc/httpd/fastcgi/php-fcgi-starter", referer http://xxx.xxx.xx/
2018-02-12 15:48:59	xx.xxx.xx.xxx:50465	FastCGI: incomplete headers (0 bytes) received from server "/etc/httpd/fastcgi/php-fcgi-starter", referer http://xxx.xxx.xx/
2018-02-12 15:48:25	xx.xxx.xx.xxx:50413	FastCGI: incomplete headers (0 bytes) received from server "/etc/httpd/fastcgi/php-fcgi-starter", referer http://xxx.xxx.xx/
2018-02-12 15:48:19	xx.xxx.xx.xxx:50411	FastCGI: incomplete headers (0 bytes) received from server "/etc/httpd/fastcgi/php-fcgi-starter", referer http://xxx.xxx.xx/

Das Problem betrifft zwei Contao-Installationen 4.4.13 auf dem gleichen Server (Managed) bei Domainfactory. Beide Installationen laufen mit PHP 7.10. Contao-Check zeigt alles in Grün. PHP-Laufzeiten und PHP-Memory kann es eigentlich nicht sein, da mit der Paketverwaltung (Contao-Manager) keine Probleme auftreten.

Wird FastCGI deaktiviert, tritt das Problem nicht mehr.

Die Technik von Domainfactory kann serverseitig keine Probleme feststellen und vermutet das Problem bei den Scripts.
Funktioniert Contao 4.4 nicht mit FastCGI oder wo könnte das Problem liegen?

VG,
Gregor

**Spooky** · 12.02.2018, 20:11

Dazu würde ich mich direkt an DomainFactory wenden oder das zumindest im Forum posten.

**gregor** · 12.02.2018, 20:18

An DomainFactory habe ich mich ja bereits gewandt und abschließend die folgende Antwort erhalten:

Wie auch zuvor konnten die Kollegen der Technik keinen serverseitigen Fehler erkennen.

**Spooky** · 12.02.2018, 20:22

Verwendest du PHP-FPM oder tatsächlich nur FastCGI?

**gregor** · 12.02.2018, 20:29

Als PHP-Edition kann ich nur folgende Optionen auswählen:
Extended
Light
Standard
FastCGI

Von PHP-FPM steht da nichts.

**Spooky** · 12.02.2018, 20:31

Deaktiviere in den System Einstellungen mal den Frontend Cron und teste, ob das Problem dann nicht mehr auftaucht.

**gregor** · 12.02.2018, 20:38

Frontend-Cron deaktiviert, Systemwartung alles geleert, Cache über den Contao-Manager neu erstellt.
Problem bleibt auch mit deaktiviertem Frontend-Cron bestehen.

**gregor** · 13.02.2018, 08:22

Gem. diesem Blogbeitrag läuft bei df PHP-FPM.

Auch phpinfo gibt an:
Server API: FPM/FastCGI
Configuration File (php.ini) Path: /usr/local/php71-fpm
php-fpm: active

An was könnte das Problem noch liegen?

**tab** · 13.02.2018, 08:25

Steht denn zu den Fehlern nichts im Error-Log des Servers?

**gregor** · 13.02.2018, 08:31

Na klar steht da was, bitte siehe oben erster Beitrag.

Mehr steht da in den Serverlogs nicht drinnen.
Jedenfalls nicht in denen, die mir zugänglich sind.

In den Contao Logs unter var/logs steht auch nichts, was nach einem Problem mit FastCGI aussieht.

**tab** · 13.02.2018, 08:40

Eventuell dauert irgendeine DB-Abfrage zu lang, so dass der Apache in einen Timeout läuft, bevor das ausgeführte Skript (Contao Backend ...) fertig wird.

**gregor** · 13.02.2018, 08:49

Kann ich das mit "einfachen Mitteln" irgendwo erkennen oder testen, wie schnell die DB-Abfrage ist?

**tab** · 13.02.2018, 09:08

Das könnte man eventuell im Debug-Modus (app_dev.php ...) sehen. Tritt der Fehler denn direkt nach dem Anklicken auf oder dauert es eine Weile?

**gregor** · 13.02.2018, 09:22

Der Fehler tritt sofort nach dem Anklicken auf.

Klicke ich z.B. auf "Seitenlayouts" ist der 500er sofort da.
Nun klicke ich im Browser "Seite zurück" und wieder auf "Seitenlayouts" und dann funktioniert es ohne Probleme.

Mit app_dev.php habe ich bis dato noch keinen Kontakt gehabt.
Muss ich mir mal in Ruhe anschauen wie das mit der app_dev.php funktioniert.

**tab** · 13.02.2018, 09:37

Naja, dann ists wohl eher unwahrscheinlich, dass das Problem durch einen Timeout kommt.

**mlweb** · 13.02.2018, 10:29

Ich hatte so ein ähnliches Problem auch bei Webgo. Die Seite war recht bildlastig und hatte einige (offensichtlich zu viele für das Paket) Bildgrößen definiert. Bildgrößen alle herausgenommen und alle Bilder noch mal optimiert und das Problem trat irgendwann nicht mehr auf. Danach haben wir die Anzahl der vordefinierten Bildgrößen drastisch reduziert bzw. an einigen Stellen, wo der Redaktuer normalerweise nichts verändert, direkt mit HTML und selbst generierten Bildern gearbeitet.

**gregor** · 13.02.2018, 11:02

Es ist eine Contao 4.4.13 Neuinstallation.
Außer paar Platzhalterbilder und etwas CSS ist da noch nicht viel vorhanden.

An der Serverauslastung kann es auch nicht liegen.
Die Werte für Systemlast, MySQL-Verbindungen und Serverantwortzeiten liegen alle im unterem Bereich.

**tab** · 13.02.2018, 11:41

Dann bleibt ja eigentlich nur entweder ein Bug in PHP/Symfony/Contao oder eine nicht ganz saubere Systemkonfiguraion. DF hatte in der Vergangenheit laut einigen Suchtreffern schon mal ähnliche Probleme, was damals wohl mit nicht ganz zur PHP-Version kompatiblen Versionen von APC(u) und/oder OPCache zusammenhing.

**gregor** · 13.02.2018, 13:12

Nun wollte ich mal schauen was der Debug-Modus an Infos preisgibt und habe das nächste Problem.
Mag sein das es an meinen bescheidenen Konsolen-Kentnissen liegt, aber so schwer kann es ja auch nicht sein.

Ich habe mit

Code:

vendor/bin/contao-console contao:install-web-dir -p

ein User und Passwort generiert.
Die .env liegt im Root.

Rufe ich nun

Code:

 */app_dev.php/contao/login

auf, kommt die Authorisierungsabfrage.

Gebe ich die Daten ein und klicke auf "Anmelden", lädt die Seite neu und die Authorisierungsabfrage kommt erneut.
Ich kann mich über app_dev nicht einloggen.
Normaler BE Login funktioniert.
Contao-Cache ist neu erstellt.

Was mache ich hier falsch?

**Spooky** · 13.02.2018, 13:53

In manchen FastCGI Umgebungen kommt es zu diesem Problem. Siehe auch dieser Stackoverflow Post von mir: https://stackoverflow.com/a/40724919/374996
Versuche mal diese Zeile ganz am Ende der .htaccess einzufügen.

**Samson1964** · 13.02.2018, 14:09

Zitat von gregor

Als PHP-Edition kann ich nur folgende Optionen auswählen:
Extended
Light
Standard
FastCGI

Von PHP-FPM steht da nichts.

Also bei meinem ManagedServer von df) steht bei PHP 7.1.6 STABLE:

STANDARD
LIGHT
FPM/FASTCGI
EXTENDED

Gewählt habe ich Extended und die 4.4.13 läuft. Ich mußte df) nur zusätzlich bitten den RAM auf der Konsole auf 1 GB (Standard 444 MB) hochzusetzen, damit der CM Pakete installieren kann.

**Spooky** · 13.02.2018, 14:12

FPM/FastCGI wäre aber prinzipiell zu bevorzugen bei Contao 4. Siehe dazu auch https://github.com/contao/check/issues/134

**gregor** · 13.02.2018, 14:20

Vielen Dank für den Hinweis, Spooky.

Aber weder

SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

noch

RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

schaffen abhilfe.

Nur das Umstellen der PHP-Edition von "FastCGI" auf "Standard" ermöglichte mir den Zugang zum Debug-Modus.
Stelle ich wieder um auf FastCGI, ist keine Authorisierung möglich, bzw. der Auth-Requester geht nicht weg.

**Spooky** · 13.02.2018, 14:26

Zitat von gregor

noch

Code:

RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

schaffen abhilfe.

Das sollte sowieso schon drin sein: https://github.com/contao/manager-bu...access#L21-L23

**gregor** · 13.02.2018, 14:39

@Samson1964

Ich verwende 7.1.10Latest mit FastCGI.
Probleme mit Laufzeiten und/oder Speicher bezüglich CM habe ich auf dem Server nicht.
Schon mit Contao 3.5 und Composer lief alles bestens.

**swinde** · 13.02.2018, 17:24

Hallo!

gibt es in Deiner php.ini diesen Link?

PHP-Code:


/usr/local/php5/ZendOptimizer.so

Wenn ja schalte "zend_optimizer.enable_loader" aus, dann sollte der Fehler weg sein, macht bei php 7 ja auch keinen Sinn!

Du kannst ja auch mal den Cgi Debugger benutzen. https://www.df.eu/blog/cgi-debugger-zur-fehleranalyse/

Siehe auch hier: https://www.df.eu/forum/threads/8063...in-der-php-ini

**gregor** · 14.02.2018, 09:02

Hallo swinde,

vielen Dank für den Hinweis.
Leider brachte das auch keine Abhilfe.

Die php.ini sieht nun wie folgt aus:

zend_optimizer.optimization_level = "15"
zend_optimizer.enable_loader = ""
zend_extension = "/usr/local/php5/ZendOptimizer.so"

Das Problem mit der Authorisierung für den Debug-Modus besteht auch noch weiterhin.

**swinde** · 14.02.2018, 09:38

Moin Gregor,

benutze doch wie von mir vorgeschlagen der CGI-Debuger auf deinem Server, der wird doch von DF kostenlos zur Verfügung gestellt.

Rufe den Debuger über den Link https://sslsites.de/ihre-domain.tld/...cgi/cgi-debug/ auf. "ihre-domain.tld" durch deine Domain ersetzen.
Der Benutzer ist die Auftragsnummer A12345, das Passwort wie beim Kundenmenü.

Damit hast du Einblick ins apache.log des Servers, jetzt noch den Fehler reproduzieren und dort nachsehen ob im Log etwas aufgelaufen ist.

Steffen Winde

**gregor** · 14.02.2018, 09:47

Mosche Steffen,

den verwende ich bereits.
Siehe das erste Posting, die Einträge sind aus dem CGI-Debugger.
Mehr wird da nicht angezeigt.

**gregor** · 14.02.2018, 09:49

Ich werde nachher mal die 7.1.6STABLE, wie auch bei Samson1694, einstellen und schauen ob sich was ändert.

**gregor** · 14.02.2018, 10:50

Umgestellt auf 7.1.6STABLE und Problem bleibt weiterhin bestehen.

**swinde** · 14.02.2018, 10:55

Bist du durch Module auf php 7.1 festgelegt oder kannst Du auch mit php 5.6 testen?

Ich würde auch optional auch mal die STANDARD Version versuchen.

**gregor** · 14.02.2018, 11:10

Mit STANDARD hatte ich es bereits versucht und hier funktioniert es ohne Probleme.

**creativx** · 03.07.2018, 07:30

Guten Morgen zusammen,

ich habe genau das selbe Problem. Ich erhalte auch ständig im Backend einen 500er. Im CGI-Debug steht folgenes drin:

Code:

2018-07-03 07:12:48	2003:a:371:1500:c577:ad45:5d4e:692c:49800	FastCGI: incomplete headers (0 bytes) received from server "/etc/httpd/fastcgi/php-fcgi-starter", referer https://www.***/

Ist die Umstellung auf PHP Standard die einzige Lösung die sich hier bisher aufgetan hat? ist das ein Problem von DF oder ein Problem, welches mich bei anderen Hostern auch erwischen kann ?

**gregor** · 03.07.2018, 08:36

Die Umstellung ist für mich bis dato die einzigste Lösung des Problems.
Ich habe bei drei anderen Hostern vergleichbare Installationen am laufen und dort treten diese Probleme nicht auf.

**creativx** · 03.07.2018, 08:38

okay - danke für die Info.

Ich werde auch nochmal versuchen bei DF etwas zu erreichen. Aber leider bewegen die sich nicht so wirklich

**creativx** · 03.07.2018, 11:38

Ich nochmal

Hier die Antwort des Supports von DF auf meine Frage hin, was wir gegen diesen Fehler unternehmen können:

Hallo Herr ***,
vielen Dank für Ihre E-Mail.
Der genannte Fehler ist bei uns bekannt, kann aber aktuell oder akut nicht gelöst werden. Es besteht nur die Möglichkeit auf FastCGI zu verzichten.

Wir arbeiten diesbezüglich und auch wegen anderer Punkte an einem allgemeinen und globalen Update der System-Umgebung. Einen Zeitraum oder Zeitpunkt dafür kann ich aber nicht nennen.

Tolle Show....

Ist die Verwendung von FastCGI denn eher als "Luxus"-Feature zu sehen, oder kann man es durchaus als Stand der Technik und als Standard betrachten? Mir fehlt da die richtige Einschätzung dafür.

**Spooky** · 03.07.2018, 15:19

Stand der Technik wäre PHP-FPM (PHP via FastCGI Process Manager).

**hinzke** · 04.07.2018, 13:50

Ich bekomme von DF eine Mitteilung sobald der Bug behoben ist und informiere euch dann auch

**creativx** · 04.07.2018, 13:55

Zitat von hinzke

Ich bekomme von DF eine Mitteilung sobald der Bug behoben ist und informiere euch dann auch

WOW, im Ernst? Ich habe auf mein Ticket hin lediglich die Antwort bekommen, dass sie mir keinen Zeitplan nennen können, bis wann das behoben sein wird. Da bin ich ja mal gespannt