cron.php.sh verwendet alte php.ini

  • Vor einiger Zeit brauchte ich den ZendGuardLoader und habe die entsprechenden php.ini-Zeilen über LiveConfig hinterlegt. Vor einer Weile habe ich den Server auf eine Debian 9 Installation migriert und dabei den ZendGuardLoader nicht mehr mit installiert, seit der Migration gibt es also auch die entsprechende php.ini-Konfiguration nicht mehr. Durch die neue Debian-Version war nun PHP 7 installiert, PHP 5.6 habe ich über das LiveConfig Repo nachinstalliert.


    Seit diesem Update funktioniert auch unter diesen Bedingungen der PHP-Session-Cronjob (/usr/lib/liveconfig/cron.php.sh) wieder und ich erhalte nun alle halbe Stunde die Fehlermeldung, dass der ZendGuardLoader nicht gefunden werden kann. Die Konfiguration dafür wurde zwar entfernt, aber nur in den php.inis in webX/conf/php7 und php56. Das Cron-Script verwendet hingegen die Ordner php7 und php5; letzterer ist eigentlich veraltet und sollte von dem Cron-Script auch gar nicht berücksichtigt werden oder?

  • Hier was ähnliches:


    Seit dem Upgrade auf Debian 9 (mit liveconfig-meta) ist /usr/bin/php ja in der Version 7.. (Wogegen /usr/bin/php-cgi weiterhin in der 5.6 geblieben ist)


    In der Datei /usr/lib/liveconfig/cron.php.sh wird dann folgender Befehl ausgeführt:


    Code
    elif [ -e '$cust/conf/php5/php.ini' ]; then
          cur=$(php -c "$cust/conf/php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')


    Wenn nun in der php.ini (PHP 5.6) z.B. der IonCube-Loader eingebunden ist, kommt es zu der Fehlermeldung:


    Code
    Failed loading ../ioncube_loader_lin_5.6.so:  ../ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change


    Warum ist wohl klar..

  • Seit dem Upgrade auf Debian 9 ist /usr/bin/php ja in der Version 7.. (Wogegen /usr/bin/php-cgi weiterhin in der 5.6 geblieben ist)


    Nein, ist es nicht. php-cgi ist ein Symlink auf /etc/alternatives/php-cgi und das ist ein Symlink auf /usr/bin/php-cgi7.0 und damit:
    /usr/bin/php-cgi --version
    PHP 7.0.19-1 (cgi-fcgi) (built: May 11 2017 14:04:47)


    Gerade getestet an einem von Jessie auf Stretch aktualisierten LiveConfig-System.

  • Nein, ist es nicht. php-cgi ist ein Symlink auf /etc/alternatives/php-cgi und das ist ein Symlink auf /usr/bin/php-cgi7.0 und damit:
    /usr/bin/php-cgi --version
    PHP 7.0.19-1 (cgi-fcgi) (built: May 11 2017 14:04:47)


    Gerade getestet an einem von Jessie auf Stretch aktualisierten LiveConfig-System.


    Siehe: https://www.liveconfig.com/wiki/de/upgrade/debian#php-7 ;)


  • Ja, bei unseren Tests wurde eben nicht automatisch auf PHP7 aktualisiert. Kleine Unterschiede im Upgrade-Workflow können aber zu anderen Ergebnissen führen.


    Zum Thema:

    Code
    elif [ -e '$cust/conf/php5/php.ini' ]; then
          cur=$(php -c "$cust/conf/php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')


    Hmm, LiveConfig ging an der Stelle davon aus, dass /usr/bin/php in der Version 5.x vorliegt und nutzt daher das "Standard"-Verzeichnis der php.ini (~/conf/php5/).
    Wir haben das Session-Aufräum-Script inzwischen modifiziert, so dass die PHP-Version explizit ausgelesen wird. Die Änderungen sind in LiveConfig v2.5.2 drin (sollte heute Abend bereits als Preview bereitstehen).


  • Hmm, LiveConfig ging an der Stelle davon aus, dass /usr/bin/php in der Version 5.x vorliegt und nutzt daher das "Standard"-Verzeichnis der php.ini (~/conf/php5/).
    Wir haben das Session-Aufräum-Script inzwischen modifiziert, so dass die PHP-Version explizit ausgelesen wird. Die Änderungen sind in LiveConfig v2.5.2 drin (sollte heute Abend bereits als Preview bereitstehen).


    Super, vielen Dank!

  • Wie bitte? Bitte genauer beschreiben, was wo wie eingebunden wird, danke!


    Also: als CLI ist z.B PHP 7.1 oder 7.2 eingebunden.
    cron.php.sh interessiert es aber nicht, ob standardmäßig 7.0, 7.1 oder was auch immer läuft. Es wird nur die Major-Version abgefragt, siehe

    Code
    PHPVERSION=`php -r 'echo phpversion();' | cut -d '.' -f 1`


    und dementsprechend auch nur die php.ini der 7.0 geladen:

    Code
    php -c "$cust/conf/php7/php.ini" ...


    hast du standardmäßig 7.1 als CLI laufen, dann wird also trotzdem "$cust/conf/php7/php.ini" und nicht "$cust/conf/php71/php.ini" beim Durchlaufen der Cronjobs eingebunden. Und das führt in Einzelfällen zu Fehlern -> z.B wenn man Ioncube über das Kundeninterface eingebunden hat.

  • Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.


    Es geht hier um die cron.php.sh von LiveConfig selbst, nicht um die Cronjobs der Verträge.


    Zitat

    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.


    Die Cronjobs der Kunden/Nutzer müssen schon auch die richtige CLI-PHP-Version verwenden. LiveConfig ändert den Cron-Befehl nicht ab.


    Dieser ist auch unabhängig von jeglicher Domain-PHP-Konfiguration.


  • Die Cronjobs der Kunden/Nutzer müssen schon auch die richtige CLI-PHP-Version verwenden. LiveConfig ändert den Cron-Befehl nicht ab.


    Das ist das Problem: die "richtige" CLI-PHP-Version ist entweder 5.6 oder 7.0. Weil nur eine der beiden dazugehörigen INIs geladen wird.


    Nochmal zu Verdeutlichung. Das Problem entsteht, wenn man seine Standard-PHP-CLI ändert.
    Spätestens mit der nächsten Debian-Version, in der dann PHP 7.2 als CLI Standard sein wird, muss die cron.php.sh angepasst werden. Ich hab es jetzt einfach hard da reingecodet (was vermutlich mit dem nächsten LC-Update wieder hinfällig ist).

  • Ich hab die cron.php.sh mal angepasst. So würde die immer die richtige php.ini laden. Es sei denn, wir bekommen PHP 8. Aber dafür sollte das Script komplett überarbeitet werden, und ggf. die PHP-Conf-Ordner immer mit zweistelligen Versionsnummer angegeben werden: also 70, statt 7.


    Zunächst habe ich die Suche anpasst:

    Code
    # detect version of default PHP-CLI binary:
      PHPVERSION=`php -r 'echo phpversion();' | sed -e 's/\.//g' | cut -c1-2`


    ergibt z.b. 56, 70, 71 etc.
    Den Ordner /var/www/kunde/conf/php70/ gibt es nicht, der heißt schlicht php7. Von daher muss das gefiltert werden:

    Code
    if [ '$PHPVERSION' = '70' ]; then
        PHPVERSION="7"
      fi


    Für die Abfrage, ob es sich um 5 oder 7 handelt, brauchen wir noch die Major-Version:

    Code
    PHPMAJOR=`echo $PHPVERSION | cut -c1`


    Dann könnte die ini dynamischer als bisher geladen werden:

    Code
    if [ 'x$PHPMAJOR' = 'x7' ] && [ -e '$cust/conf/php$PHPVERSION/php.ini' ]; then
            cur=$(php -c "$cust/conf/php$PHPVERSION/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')
          elif [ -e '$cust/.php5/php.ini' ]; then
    ...


    Den PHP 5-Block hab ich absichtlich unangetastet gelassen. Da ist scheinbar eine Rückwärtskompatibilität eingebaut worden.


    Das ganze Script sieht so bei mir aus:

  • Um die Ausgangsfrage zu beantworten:


    Ich muss mich auch mal hier reinhängen. Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.
    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.


    Nein, tut es nicht.


    cron.php.sh macht nichts anderes, als die Session-Lifetime aus den vorhandenen php.inis auszulesen. Anhand dessen wird dann pro Kunde ein Find durchgeführt, um die Session-Dateien aufzuräumen.


    Ich sehe hier keinerlei Referenz in irgendeiner Art und Weise, die auch nur ansatzweise einen Zusammenhang zu IonCube oder Zend benötigen würde.


    Wenn ein Kunde(!) seine Cronjobs mit PHP-CLI benötigt, dann muss er so oder so den absoluten Pfad verwenden, der vom Provider vorgegeben wird. Diese Cronjobs, die der Kunde in der GUI konfigurieren kann, sind vollkommen unabhängig von einer Domain und somit auch unabhängig von der PHP-Version der CLI oder sonstwem.

  • Naja, aber scheinbar werden die in Liveconfig angelegten Cronjobs über cron.php.sh aufgerufen, oder nicht? Jedenfalls hatte ich, nachdem die PHP-CLI umgestellt wurde, diese E-Mail in der Mailbox:
    https://imgur.com/a/LTq9J
    Kunde hat php7.1. Das Script lädt aber die ini der 7.0


    Ich habe dann in cronjob.php.sh ein paar Variablen ausgeben lassen, um sicherzugehen, was da passiert. Und dadurch bin ich auf dieses Problem gestoßen.


    Edit: würde im Cronjob ein absoluter PHP-Pfad, statt einfach nur php, bzw. /usr/bin/php angegeben, dann würde er ja trotzdem die php.ini der 7.0 laden

  • Also ich kenne das Problem ebenfalls von einigen, aber nicht von allen Servern.
    Bei allen betroffenen Servern wurde ein Upgrade von Debian 7 auf Debian 8 durchgeführt und systemweit PHP5.x durch PHP7.0 als Standard ersetzt.


    Seither liefert der LiveConfig CronJob "/usr/lib/liveconfig/cron.php.sh" eine Fehlermeldung

    Zitat

    Failed loading /usr/local/ioncube/ioncube_loader_lin_5.6.so: /usr/local/ioncube/ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change
    Failed loading /usr/local/ioncube/ioncube_loader_lin_5.6.so: /usr/local/ioncube/ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change


    Eine Korrelation zwischen irgendeinem Kunden CronJob bzw. in LiveConfig angelgeten CronJob kann ich nicht bestätigen.


    Allerdings ist bei einem (!!!) Vertrag auf dem Server der IonCube Loader aktiviert.
    Und das mit der PHP Version 5.6


    Da cron.php.sh aber NICHT mit PHP5.6 ausgeführt wird (systemweit ist ja PHP7 aktiv) wird hier die Fehlermeldung erzeugt und per Mail verschickt.
    Wenn ich in dem einen Vertrag den IonCube Loader deaktiviere, wird logischerweise auch die Fehlermeldung nicht mehr ausgegeben.


    Dazu ist anscheinend in LC 2.5.2-r4777 auch eine Änderung in LC eingeflossen.

    Zitat

    Prüfung der PHP-Version (php-cli) damit Session-Aufräum-Script per Cron die richtige php.ini verwendet


    Allerdings scheint der Patch das obige Problem nicht (korrekt) zu lösen.



    EDIT: Auf den betroffenen Servern läuft entweder LC 2.6.0-r4817 oder LC 2.5.3-r4805

  • Allerdings scheint der Patch das obige Problem nicht (korrekt) zu lösen.


    Weil ich den Part mit PHP 5 komplett außer acht gelassen habe.


    Du hast ioncube scheinbar nicht über die PHP-Einstellungen in LC eingebunden, oder? Bzw. mit dem Hinweis, dass /usr/local/ioncube/ioncube_loader_lin_5.6.so nur für PHP >= 5.6 und <7 gilt.


    Bei mir sind drei ioncube Versionen eingebunden, jeweils passend zur PHP-Version.

  • Es geht hier ja letztendlich nur um das Session-Cleanup-Script /usr/lib/liveconfig/cron.php.sh
    Wir gehen dabei davon aus, dass auf dem Server das Paket "php-cli" installiert ist, welches die Datei /usr/bin/php bereitstellt.
    Ab Ubuntu 16 und Debian 9 ist "php-cli" ein virtuelles Paket, das auf "php7.0-cli" verweist.
    Das cron.php.sh ist eigentlich darauf ausgelegt, mit dem jeweiligen "System"-PHP-CLI ausgeführt zu werden. Wenn das System-Paket (php7.0-cli) nicht installiert ist, dann erzeugt LiveConfig auch keinen "/conf/php7"-Pfad, was dann zu Fehlern mangels richtiger php.ini führt.


    Wer also manuell die /usr/bin/php umbiegt, wird zwangsläufig auch das cron.php.sh-Script anpassen oder ersetzen müssen.


    "Unsere" PHP-Pakete werden übrigens demnächst überarbeitet, so dass diese sich "alleine" bei LiveConfig registrieren (ohne addPHP()-Aufruf in der custom.lua). Da werden dann auch die CLI-Binaries registriert, und die können dann auch vom cron.php.sh-Script verwendet werden.


  • Wer also manuell die /usr/bin/php umbiegt, wird zwangsläufig auch das cron.php.sh-Script anpassen oder ersetzen müssen.


    Danke für die ausführliche Antwort. Das bestätigt ja mein Handeln. Bleibt die cron.php.sh bei Minor-Updates von LC unberührt?


    Ich musste übrigens die php-cli umbiegen, weil ich sehr viele Symfony-Installationen habe und viele Pakete mindestens 7.1 erfordern (die werden über Composer per CLI installiert/geupdatet). Klar, ich kann jedesmal /opt/php71/... schreiben, aber das ist auf Dauer lästig.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!