Manger beleibt bei "Lade" Konsolentask" stehen

[kroerig]

Hallo,

bei mir bleibt der Manager neuerdings bei "Lade Konsolentask" stehen. Er kommt noch nicht mal soweit irgendwelche Logs o.ä. zu erzeugen. Ich kann mich anmelden bzw. einen Account erzeugen und danach ist feierabend.

Die einzige Fehlermeldung, die ich in den Serverlogs finden kann ist diese:

[25-Oct-2018 17:39:43 Europe/Berlin] PHP Fatal error: Phar::webPhar(): Failed opening required 'phar:///var/www/web0/html/www.bergischer24stundenlauf.de/contao4/web/contao-manager.phar.php/web/api.php' (include_path='.:/opt/php-7.2/lib/php') in /var/www/web0/html/www.bergischer24stundenlauf.de/contao4/web/contao-manager.phar.php on line 99
Der macht einfach nichts mehr.

 ----------------------- ------------------------------------------------------------------------------------------------------------------
  Contao Manager
 ----------------------- ------------------------------------------------------------------------------------------------------------------
  Version                 1.0.4
  Environment             prod
  Debug                   false
  Cache directory         phar:///var/www/web0/html/www.bergischer24stundenlauf.de/contao4/web/contao-manager.phar.php/api/Resources/cache
  Contao directory        /var/www/web0/html/www.bergischer24stundenlauf.de/contao4
  Data directory          /var/www/web0/html/www.bergischer24stundenlauf.de/contao4/contao-manager
 ----------------------- ------------------------------------------------------------------------------------------------------------------
  PHP
 ----------------------- ------------------------------------------------------------------------------------------------------------------
  Version                 7.2.11
  Architecture            64 bits
  Server API              cli
  Intl locale             en_US
  Timezone                Europe/Berlin
  Binary Path             /opt/php-7.2/bin/php
 ----------------------- ------------------------------------------------------------------------------------------------------------------

Per Composer auf der CLI kann ich alles machen. Contao selbst läuft auch wunderbar.

[aschempp]

Kann es sein dass die Phar defekt ist? Oder hast du sie per Symlink wohin "kopiert"?

[kroerig]

Nein, ganz simpel von der Homepage geladen.
Auf dem Server liegen 5 Contao 4 Installationen und bei keiner funktioniert er mehr.

Los ging es mit dieser Meldung bei einer der Installationen:

ERROR 500 The Contao version could not be determined The console returned unexpected content when asked for the Contao version. Please check the output for more information: 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), /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0 4.4.17

Dann habe ich mal geschaut, ob es Paketupdates gibt, und diese eingespielt. Danach lief dann gar nichts mehr.

Der Betreuer der PHP-Paket sagt, bei ihm läuft der Manager. Aber wie kriege ich raus, warum er bei mir nicht mehr will?

[Toflar]

PHP Warning: Failed loading Zend extension 'opcache.so' ..... Dein PHP gibt auf der Kommandozeile Warnings aus, ist also nicht korrekt konfiguriert. Bitte deinen Hoster das zu reparieren.

[kroerig]

Die Meldung ist weg. Contao selbst funktioniert ja auch ohne irgendwelche Fehlermeldungen.

Die einzige Fehlermeldung, die ich jetzt noch in den Logs sehen, ist die aus dem ersten Post. Nur das die leider wenig aussagekräftig ist.

[Toflar]

Der Webserver nutzt ein anderes PHP-Binary als der Manager. Der Manager nutzt sowohl das für das Web als auch das für die Kommandozeile (CLI). Beide müssen korrekt konfiguriert sein, was leider oft nicht der Fall ist, weil bei vielen Webhostern die CLI leider vernachlässigt wird. Von daher kann es sehr gut sein, dass Contao einwandfrei läuft, aber die Konsolentasks des Managers nicht.

[kroerig]

Ja, das ist mir schon klar, das hat ja auch bis letzte Woche problemlos funktioniert.
Dann wollte ich über den Manager eine Demo-Installtion aufsetzen, und bekam die 500er Fehlermeldung. (Da liefen aber die anderen Instanzen auf dem Server noch problemlos).

Dann habe ich mal die aktuellen Updates eingespielt und jetzt bleibt er hängen.

Wenn ich den "contao-manager"- Ordner lösche, kann ich beim nächsten Aufruf noch einen neuen Benutzer anlegen, aber bis zur Eingabe des PHP-Pfade komme ich schon nicht mehr.

[kroerig]

So, Problem eingegrenzt. Es hängt irgendwie mit der zend_extension für Opcache zusammen.
Wenn ich die rausnehme, läuft der Manager wieder.

Jetzt muss der Ersteller der PHP-Pakete mal schauen, was da in den Abhängigkeiten nicht stimmt.

Wäre aber hilfreich, wenn der Contao-Manager das irgendwie abfangen könnte.

[kroerig]

So, das PHP Warning dürfte daher gekommen sein, dass sich ein paar Pakete aus einem anderen Repro eingeschlichen hatten, die nicht zueinander passten.
Das habe ich jetzt wieder glatt gezogen. Hat aber den Fehler nicht behoben.

Die o.g. genannte Fehlermeldung ist leider nicht sehr aussagekräftig. Lässt ich der Contao-Manager irgendwie etwas gesprächiger machen?

[aschempp]

Welche Fehlermeldung? Auf die PHP-Warnungen hat der Manager keinen Einfluss, dazu müsstest du aber bei Google sicher was finden?

[kroerig]

Diese hier:
'Failed opening required 'phar:///var/www/web0/html/www.bergischer24stundenlauf.de/contao4/web/contao-manager.phar.php/web/api.php''
Er versucht ja auf Inhalt in dieser phar-Datei zuzugreifen, was nicht gelingt. Bei einer normalen php-Datei würde ich hier irgendwas im Error-Log des Apaches finden. Bei den phar-Dateien taucht da nichts auf.

[knollraf]

Hallo zusammen,

gibts schon einen Fortschritt?

Habe vermutlich das selbe Problem. Der Manager bleibt sowohl bei All-inkl. als auch local (MAMP) bei der Installation stehen.
Leider habe ich keine Fehlermeldung - alles was angezeigt wird ist:
"Downloading application template …
contao/managed-edition 4.4.*
Warte auf Konsolenausgabe …"
--> Ab hier geht gar nichts mehr voran.
Es wurde lediglich der "contao-manager"-Ordner mit der config, manager, task und user.json angelegt.

[aschempp]

@knollraf ich verstehe nicht was dein Kommentar mit diesem Ticket zu tun hat?

[keppler]

@knollraf hat offenbar das selbe Problem wir @kroerig.
Wir haben das in einer lokalen Testumgebung reproduzieren und lösen können (LiveConfig).
Offenbar besteht das Problem nur dann, wenn man Opcache mit Shared Memory aktiviert hat, und die Einstellung opcache.validate_permission aktiviert ist.
In Shared-Hosting-Umgebungen ist es i.d.R. zwingend, opcache.validate_permission zu aktivieren (alle Pools der selben FPM-Instanz teilen sich den selben Shared Memory - würde man die Berechtigungen nicht prüfen, kann man ggf. auf gecachte Inhalte anderer User zugreifen).

Ich persönlich vermute, dass es sich hier irgendwo um einen Bug in PHP handelt, da dieses Verhalten offenbar nur bei Phar Probleme macht.

Lösungen
Es gibt drei Workarounds:

1. opcache komplett abschalten. Sollte man sich bei FPM im Shared Hosting eh gut überlegen. ;-)
2. opcache.validate_permission=Offsetzen. Keine gute Idee, sofern noch andere User auf dem Server sind.
3. opcache.file_cache_only=On setzen. Das dürfte in den meisten Fällen die beste Lösung sein.

Der Fehler tritt übrigens unabhängig davon auf, ob man PHP via FastCGI oder via FPM laufen lässt.

[leofeyer]

In Shared-Hosting-Umgebungen ist es i.d.R. zwingend, opcache.validate_permission zu aktivieren (alle Pools der selben FPM-Instanz teilen sich den selben Shared Memory

Soweit ich weiß trifft das nur zu, wenn es nur einen Master-Prozess gibt, der die Client-Prozesse für alle Benutzer spawnt (siehe https://ma.ttias.be/mitigating-phps-long-standing-issue-opcache-leaking-sensitive-data/). Wenn man PHP-FPM so einrichtet, dass jeder Benutzer einen eigenen Master-Prozess hat, braucht man validate_permission nicht IMHO. Auch so Sachen wie "maximale Anzahl an Client-Prozessen pro Benutzer" lassen sich überhaupt nur umsetzen, wenn jeder Benutzer einen eigenen Master-Prozess hat.

[keppler]

Völlig korrekt.
Allerdings ist es im Mass Shared Hosting bislang unüblich, einen eigenen FPM-Master pro Benutzer zu starten (damit gibt man ja eigentlich genau den Vorteil von FPM gegenüber Apache mod_fcgid auf). Es gibt Ansätze, das mit systemd und Socket Activation zu optimieren, das ist aber dann eher etwas für (sehr) fortgeschrittene Admins.
Die einfachste Lösung des opcache-Sicherheitsproblems ist es daher, den Shared Memory abzuschalten - somit sollten keine Daten mehr zwischen den einzelnen Pools geteilt werden...

[kroerig]

Könnte der Manager diese PHP-Einstellungen prüfen und abfangen, statt sich den Strick zu nehmen?

[frontendschlampe]

Gibt es zu diesem Thema irgendwelche Updates/Vorgehensweisen? Bin ebenfalls in das Problem gerannt!

[aschempp]

Ich persönlich vermute, dass es sich hier irgendwo um einen Bug in PHP handelt, da dieses Verhalten offenbar nur bei Phar Probleme macht.

Ich wüsste nicht wie wir das Problem im Manager lösen sollen. Ausser man könnte den OpCode Cache komplett deaktivieren (@Toflar ?)

[Toflar]

Also Opcache generell zu deaktivieren ist natürlich Schwachsinn. Für den Betrieb der Applikation ist der ja relevant. Nur für den Manager ist er das nicht, weil Performance für uns nicht wirklich ein Thema ist.
Aber ich denke das können wir nicht dynamisch. opcache.enable ist zwar PHP_INI_ALL, sprich es kann für den aktuellen Request überschrieben werden, aber zu dem Zeitpunkt ist ja das Skript bereits geparst und im Opcache. Und was die Konsole betrifft, opcache.enable_cli könnte ja auch aktiviert sein und die ist PHP_INI_SYSTEM, kann also nur in einer .ini für CGI und FPM bzw. bei mod_php in der httpd.conf gesetzt werden. Also noch wenn wir den Opcache für den Webprozess deaktivieren könnten, so könnte es immer noch auf CLI zu Problemen kommen.

Wenn es wie hier beschrieben nur an opcache.validate_permission liegt und ansonsten funktioniert, wäre es imho viel schlauer, einen reproduzierbaren Case mit einer möglichst kleinen Phar zu bauen und das bei PHP zu reporten, damit es ggf. gefixt werden kann.
Aber ich werd das nicht tun 😄

[kroerig]

Da bin ich leider auch raus, da ich von der Entwicklung keine Ahnung habe.

Aber könnte der Manager diese Konstellation nicht beim beim Setup/ Starten abfragen und dem Anwender zumindest einen Warnhinweis geben bzw. sich mit einer aussagekräftigen Fehlermeldung beenden?

Also die Kombi aus:
opcache.enabled
opcache.validate_permission=1
opcache.file_cache_only=0

In diesem Fall läuft er ja gegen die Wand.

[aschempp]

opcache.enabled liesse sich als erstes in der stub.php deaktivieren, dann müsste es doch für alle weiteren Scripts im Phar nicht angewendet werden? Die Stub ändert sich praktisch nie…

[Toflar]

Ja, das ist korrekt. Also das stub File (wird nicht als phar://stub.php sondern als pfad/zur/contao-manager.phar.php abgelegt) wird im Opcache gespeichert, alle nachfolgenden Skripte (die wären dann unter phar://pfad/zur/datei abgelegt) würden dann ignoriert. D.h. Änderungen am Stub-File sind gecached und das kannst du auch nicht beeinflussen, aber der ganze Rest nicht.
Wenn du dir Änderungen an der stub.php auch noch vorbehalten möchtest, müsstest du sowas als deine stub.php nehmen:

<?php
ini_set('opcache.enable', '0');
include_once 'real_stub.php';
__HALT_COMPILER();

Oder so ähnlich, you get the point.

[aschempp]

Should be fixed in da4dc42 then.