Probleme mit Symfony-Anwendungen

  • Hallo zusammen,


    ich betreue mehrere Kunden, die in ihren Accounts verschiedenste Symfony-Anwendungen (SF4 auf PHP 8.1) im Webhosting-Paket laufen haben. Seit ca. einer Woche gibt's hier allerdings ziemliche Probleme. Diese funktionieren plötzlich nicht mehr obwohl an den Anwendungen keine Veränderungen vorgenommen wurden. Es ist die Netcup-Internal-Server-Error-Seite zu sehen und in den Logs nur Folgendes:

    Zitat


    (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server

    End of script output before headers: index.php

    Bei einigen Kunden konnte ich das Problem "umgehen", indem ich den Doctrine-Cache-Pool deaktiviere. Bei komplexeren Anwendungen (wie z. B. einer Sulu-Installation) hilft gar nichts.


    Gibt's hier weitere Symfony-Nutzer, die ähnliche Probleme haben/hatten? Ich vermute Änderungen an PHP-Erweiterungen oder -Konfigurationen seitens netcup.

  • Hay,


    Zitat

    End of script output before headers: index.php

    leider kein Symphony Nutzer. Aber die Meldung spricht dafür, dass bevor die index.php Headerzeilen erzeugt, wird normaler Output erzeugt - was nicht sein darf.


    Da gibt es den "klassischen Fehler", dass vor dem einleitenden <?php noch eine Leerzeile oder Leerzeichen in einer manuell erstellten index.php vorkommt, das lässt sich aber bei einer unmodifizierten Symphony-index.php eigentlich ausschließen.


    Bleibt nur übrigt, dass dieser Output unter Umständen eine Fehlermeldung ist. Die sollte entweder geloggt sein (access log oder error log). Wie man bei symphony einen debug output erzeugen kann, weiß ich leider nicht, aber ggf. sollte es da auch noch eine Möglchkeit geben. Ein paar Experimente mit Lumen (bzw. Laravel) haben da erschreckend viel Output erzeugt, wenn ich das wollte.


    "Spaßeshalber" kannst Du ja mal versuchen, in den php-Einstellungen php fpm zu versuchen. Es sieht für mich nämlich außerdem so aus, als ob irgendwas im Timing zwischen nginx-Proxy und dem Apache schief gehen könnte - also enstprechende timeouts ggf. zu überprüfen und zu modifizieren.


    Soweit zu allgemeinen-nicht-symphony-spezifischen Hilfe.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Hey Peter,


    vielen Dank für deine Antwort. Da hast du auf jeden Fall Recht - allerdings auch damit, dass es ohne Modifikation auch nicht "einfach so" auftreten sollte. Vor allem auch zeitpunktgenau bei mehreren WCP-Kunden und Symfony-Installationen. Zum Symfony-Logging kommt es an der Stelle gar nicht. Es muss also vorher schon irgendwo haken.


    Interessant finde ich deinen Hinweis zu php-fpm. In meinen WCPs habe ich diese Option gar nicht mehr. Das war mal bei alten PHP-Versionen vorhanden. Mir steht nur die Option "FastCGI-Anwendung (Apache)" zur Auswahl. Hast du mit PHP 8.1 noch die FPM-Option?

  • Ja, php-fpm steht schon seit längerer Zeit (ab PHP 7.3?) nicht mehr zur Auswahl. Ist es möglich, dass auf den Webhostingservern der betroffenen Accounts kürzlich "Wartungsarbeiten" angekündigt und mittlerweile durchgeführt wurden? Das war bei mir z.B. auf a2f8d der Fall. Da habe ich momentan aber keine Symfony-Anwendung aktiv, kann das aber notfalls mal antesten. Auf anderen Servern allerdings schon, auf a2e4f wurden die selben(?) Wartungarbeiten bereits im August durchgeführt, da läuft bei mir eine Symfony 5 Anwendung ohne Probleme. Symfony 4 habe ich mittlerweile nicht mehr im Einsatz, da kann ich insofern auch nicht ohne Weiteres eine Testinstallation machen.

  • Hay,

    Interessant finde ich deinen Hinweis zu php-fpm. In meinen WCPs habe ich diese Option gar nicht mehr.

    php-fpm steht schon seit längerer Zeit (ab PHP 7.3?) nicht mehr zur Auswahl.

    oha. Ok, ich betreibe meine Server und nur ein kleines Webhosting zum Spielen, da habe ich aber seit längerem nicht mehr reingeschaut. Trotzdem liegt mein Gedanke immer noch beim Timing, "hochoffziell" wird sich jetzt offensichtlich schon darum gekümmert... ^^


    ... und würde mich auch darüber freuen, wenn wir alle die Ursache berichtet bekommen - einfach um noch ein Stückchen Erfahrung zu sammeln.


    Ich drücke die Daumen.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Hallo zusammen,


    wir konnten die Ursache finden und arbeiten aktuell an der Behebung. Vielen Dank auch an dukkha für die Mithilfe.


    Am 13. September haben wir eine neue Version von PHP 8.1 ausgerollt und damit zusammen auch erstmalig den Ioncube Loader für PHP 8.1. Wir haben diesen zuvor gründlich und gewissenhaft getestet und zudem erst einige Versionen (von Version 12.0 bis 12.0.2) abgewartet. Dennoch scheint auch die aktuelle Version des Ioncube Loaders (12.0.2) einen Bug zu beinhalten, der im Zusammenspiel mit Symfony für Abstürze des PHP-Interpreters sorgt:

    https://stackoverflow.com/a/73416943


    Da der Ioncube Loader für PHP 8.1 erst seit kurzem bei uns und auch allgemein zur Verfügung steht, haben wir uns nun dazu entschieden, diesen (temporär) zu deaktivieren. Diese Änderung rollt aktuell auf alle Webhosting-Server aus. Es kann noch einige Stunden dauern, bis diese überall greift. Anschließend ist der Sachverhalt behoben. Wir werden evaluieren, wann wir den Ioncube Loader für PHP 8.1 wieder bereitstellen können und werden.

  • Wir werden evaluieren, wann wir den Ioncube Loader für PHP 8.1 wieder bereitstellen können und werden.

    Hallo an das netcup Team,


    da es nun schon einige Aktualisierungen vom Ioncube Loader gegeben hat, möchte ich einmal nachfragen wie der aktuelle Stand ist.

    Bestehen noch Bedenken die gegen eine Bereitstellung für PHP 8.1 sprechen könnten?

    Einige Plugins vom JTL-Shop laufen nicht ohne den Ioncube Loader.


    Gruß Crashandy

  • Hallo Crashandy,


    ionCube hat den Fehler, bei dem der ionCube Loader Cache-Dateien von Symfony Doctrine als verschlüsselt erkennt und dann deshalb den PHP-Prozess zum Abstürzen bringt, bisher leider nicht behoben. Aktuell werden wir daher den ionCube Loader für PHP 8.1 weiterhin nicht bereitstellen.


    Falls es für dich eine Alternative sein könnte: Auf unseren managed Servern können wir dies individuell konfigurieren, ohne andere Nutzer zu beeinflussen, da es sich um kein shared Hosting handelt. Vielleicht sind diese ja für dich interessant, hier findest du weitere Informationen:

    Managed Private Server mit garantierten Ressourcen - netcup.de
    Webhosting, Server, Domains, Managementdienste, einfach alles fuer einen erfolgreichen Internetauftritt
    www.netcup.de

  • Hallo [netcup] Lars S.,


    vielen Dank für die weiterführenden Informationen. Da es sich bei unserem Shop nicht um ein so sehr großes Projekt handelt, werden wir nun versuchen diese Plugins durch Alternativen zu ersetzen, welche keine IonCube Loader für die Funktion benötigen.

    Mit dem Thema Managed Private Server werden wir uns eventuell noch später beschäftigen, dann könnte man vielleicht auch gleich vollständig mit den SQL-Datenbanken und der Warenwirtschaft auf den Server umziehen.


    Gruß Crashandy

  • Soeben mußte ich mit Bedauern feststellen, dass mein FileRun Update 2023.1.0 im Webhosting 2000 Produkt gescheitert ist, weil darin unter PHP 8.1 die ionCube Loader PHP Extensions zwingend erforderlich ist. Da war ich leider zu blauäugig und hätte das vorab sicher nachprüfen sollen, um das Problem zu vermeiden (und das Update abzubrechen). Mir bleiben wohl nur die beiden Möglichkeit A/ auf einen zukünftigen Patch der derzeitigen ionCube 12.0.5 Version vom Dez. 2022 zu warten, der das Problem mit den 'Cache-Dateien von Symfony Doctrine' behebt oder B/ auf eine vServer-Produkt von netcup umzusteigen. Wäre auf einem vServer ionCube denn als PHP Extension installierbar?

  • Das mag daran liegen, dass netcup die neuen PHP 8 Versionen jedes Mal sehr schnell zur Verfügung gestellt hat, lange bevor der Ioncube-Loader jeweils für die neue PHP-Version zur Verfügung stand. Und hinterher hat man den Ioncube-Loader dann wohl einfach vergessen. Also ich würde auch definitiv raten, hier mal beim Support nachzufragen. Das sollte ja kein unlösbares Problem sein und auch keine ungewöhnliche Anforderung.