Beiträge von kk

Sehr gute Frage... ich habe auf Anhieb keinerlei Dokumentation dazu finden können.
Rein intuitiv würde ich sagen, dass dieses Limit nur pro Vertrag (= pro opcache.file_cache) Sinn macht - allerdings ist PHP einfach alles zuzutrauen...

Läuft lcsam überhaupt? (ps aux | grep lcsam)
Der lcsam protokolliert seine Meldungen üblicherweise mit in /var/log/mail.log
Falls der nicht mehr läuft kann es sein, dass er z.B. vom OOM-Killer des Kernels abgeschossen wurde. Ich weiß das gerade nicht auswendig, aber so etwas sollte ebenfalls im mail.log bzw. im syslog protokolliert sein.

Zitat von Febas

Der Ordner /var/run/php7.0-fpm/ existiert nicht.

Ich vermute, dass es sich um ein Debian/Ubuntu-System ohne systemd handelt?
Dann erstellen Sie bitte einfach das o.g. Verzeichnis und führen anschließend "/etc/init.d/php70-fpm start" aus - dann sollte es klappen.
Wir aktualisieren in diesen Minuten die PHP-Pakete in unseren Repositories, die genau diesen Fehler beheben (betrifft nur Server ohne systemd).

Diese andere Meldung (mit dem "Error 500") taucht nicht mehr auf?
Ich habe in unseren Testumgebungen keinerlei Probleme mit Opcache.

Erstellen Sie ggf. mal eine phpinfo()-Datei und schicken uns deren komplette Ausgabe (oder einen Link darauf) an support@liveconfig.com, dann vergleichen wir das mal mit unserer Ausgabe.

Keine Fehlermeldung - keine Hilfe möglich...

Hallo,

ab sofort steht LiveConfig v2.7.0 zum Download bereit.

Die wichtigsten Neuheiten sind:

• Web-basierte Inbetriebnahme ("onboarding") zur Konfiguration der Lizenz, Zugangsdaten und Kontaktdaten bei Neuinstallationen
• AutoDeploy für eine vereinfachte automatisierte Installation von LiveConfig
• Unterstützung von PHP-FPM (FastCGI Process Manager)
• Unterstützung von TLS 1.3 in der LiveConfig-Oberfläche (OpenSSL 1.1.1)

Zudem gab es viele kleinere Verbesserungen und Fehlerbehebungen - die vollständige Liste steht wie immer im Changelog.

Aktuell werden unsere PHP-Pakete für Debian/Ubuntu noch mal neu compiliert, da auf Systemen ohne systemd der FPM-Prozess sonst nicht startet (deren Update steht ab morgen Vormittag im Repository).

Das LiveConfig-Update lässt sich wie immer problemlos über die regulären Paket-Updates einspielen (APT/yum/zypper).
Debian 7 ("Wheezy") wird nicht mehr unterstützt.

Viele Grüße

-Klaus Keppler

Zitat von kroerig

ii libpcre3:amd64 2:8.41-1.2+ubuntu16.04.1+deb.sury.org+1

Da haben wir die Ursache schon... Sie haben offenbar die bei Ubuntu mitgelieferte libpcre durch die Version von deb.sury.org ersetzt. Offenbar ist diese aber inkompatibel zur 8.38, daher kracht's bei PHP.
Einzige Frage wäre daher: wenn Sie ohnehin schon PCRE von deb.sury.org verwenden, warum dann nicht auch gleich die PHP-Pakete von dort?

Hmm, auf unserer Ubuntu-16-Testmaschine läuft alles problemlos, auch mit Opcache.
Da die Fehlermeldung auf ein Problem mit PCRE hindeutet, was liefern die folgenden Befehle?

ldd /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so
ldd /opt/php-7.2/bin/php | grep pcre
dpkg -l | grep pcre

Kurze Info: PHP 7.3.0 wurde auf RC4 aktualisiert.

Und: was genau liefert der Befehl "/opt/php-7.2/bin/php -v" ?

Zitat von kroerig

PHP Warning: Failed loading Zend extension 'opcache.so' (tried: /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so: undefined symbol: pcre_free), [...]

Das hilft schon mal weiter - das Problem liegt offenbar darin, dass die opcache-Erweiterung nicht geladen werden kann.
Welche Distribution genau nutzen Sie?
Sie könnten testweise mal die Datei /opt/php-7.2/etc/conf.d/opcache.ini bearbeiten und dort die zend_extension-Anweisung auskommentieren, dann sollte es vorerst wieder laufen.

Zitat von RB-Media-Group

wurde bei den ShortTags was verändert, bei einem Kunden funktionieren diese seit dem Update auch nicht mehr, im LiveConfig sind Sie aber aktiviert.

Was genau meinen Sie mit "funktionieren nicht mehr"?
Welche PHP-Version genau?
Welche Linux-Distribution?
Was für ein Update? LiveConfig oder PHP?

Seitens LiveConfig wurde bzgl. short_open_tag nichts verändert.

Welche Version genau wäre denn die "letzte Version"? Die unmittelbar vorherige?
Ich habe das eben mal mit dem aktuellen Contao Manager unter Debian 9 mit PHP 7.2.11, 7.1.23 und 7.0.32 getestet, funktioniert problemlos.
Haben Sie die php.ini-Einstellung "log_errors" mal aktiviert? Dann sollten PHP-Ausführungsfehler in ~/logs/priv/php_errors.log protokolliert werden.

Viele Grüße

-Klaus Keppler

Wird in Kürze konfigurierbar sein.

Zitat von taenzerme

Ich schließe mich da auch an. Gibt es sonst einen Workaround, um TLS 1.0 und 1.1 pro Domain oder pro Kunde zu deaktivieren?

/var/www/<Vertrag>/.httpd.conf mit folgendem Inhalt anlegen:

SSLProtocol -SSL3 -TLSv1 -TLSv1.1

und danach den Vertrag neu speichern (damit die .httpd.conf per Include in den vHost aufgenommen wird).

Viele Grüße

-Klaus Keppler

Mit v.2.7.0-r5093 werden die ggf. falsch geschriebenen opcache-Einstellungen korrigiert.
Das dürfte nur Installationen betroffen haben, auf denen LiveConfig ursprünglich mal in Version <1.7.0 lief.

Zitat von Mercator1972

Kann es sein, daß seit dieser Preview-Version fie Werte für opcache.file_cache und opcache.lockfile_path neu in Liveconfig verwaltet werden?

Diese Werte sind scheinbar leer, sodaß zumindest hier der php-Prozess (auch bei fcgi) ausstieg.

LG

Thomas

Alles anzeigen

Ja, das ist uns bereits aufgefallen. Wenn LiveConfig von einer älteren Installation auf 2.7.0 aktualisiert wurde, dann landeten leider falsche Werte in der php.ini-Verwaltung. Für die beiden opcache-Einträge bitte jeweils "%HOME%/tmp" hinterlegen, dann klappt wieder alles.
Mit v2.7.0-r5092 ist das bereits korrigiert, landet in Kürze im Repo.

Sagen wir mal: der Admin braucht <30min - wenn die Hardware langsamer ist, geht das eben "on top".

Zitat von RB-Media-Group

ich habe eine Seite von FastCGI auf FPM umgestellt, nutze PHP 7.0.32 und habe ca. 250ms schnellere Reaktionszeiten laut Pingdom Test.

Wenn eine "Website" (PHP-Code) mal komplett gecached ist, gibt es technisch keinen Geschwindigkeitsunterschied zwischen FPM und FastCGI (die Kommunikation ist exakt die selbe, nur die Prozessverwaltung unterscheidet sich etwas).

APCu ist das eine - Opcache das andere... Bei FPM läuft das technisch so ab, dass ein PHP-Interpreter tatsächlich nur ein einziges Mal gestartet wird. Für alle Worker-Pools wird dieser dann geforked. Deshalb kann keine individuelle php.ini pro Pool verwendet werden, stattdessen muss man die gewünschten INI-Anweisungen via "php_admin_*"-Befehle in die Pool-Konfiguration schreiben (die werden quasi nach dem fork() nachträglich angewendet).
Für Shared-Hosting-Systeme bedeutet das: man kann nicht mehr einzelne Zend-Extensions nur für einzelne Webspaces laden, sondern diese müssen global registriert werden.

Bei FastCGI gibt es zwangsweise mindestens eine laufende PHP-Instanz pro Vertrag und pro PHP-Version. FPM ist hier flexibler und ermöglicht es, auch den "ersten" benötigten PHP-Interpreter nur bei Bedarf zu starten. Bei Shared-Hosting ermöglicht das somit (theoretisch) eine höhere Kundendichte pro Server, insbesondere wenn der Trend zu vielen verschiedenen PHP-Versionen gleichzeitig geht.

FPM ist also nicht pauschal "schneller" als FastCGI (die Kommunikation ist in beiden Fällen sogar exakt identisch), es kommt vielmehr auf den jeweiligen Anwendungsfall an.

Seitens LiveConfig gab es keine Änderungen was suPHP betrifft - wir haben aber vor, das künftig nicht mehr zu unterstützen. Wird schließlich von Debian seit Version 8 nicht mehr bereitgestellt...
Warum das bislang lief kann ich unmöglich sagen, wird reines Glück gewesen sein.

suPHP? Mit Debian 9? Das dürfte da eigentlich gar nicht mehr verfügbar sein...
Bitte testweise auf FastCGI umstellen.
Ich vermute, dass suPHP nicht funktioniert (würde mich auch wundern) und deshalb als Fallback mod_php verwendet wird.