cron.php.sh verwendet alte php.ini

Ringelnatz · 27. Oktober 2017

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?

Febas · 28. November 2017

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..

aziegler · 29. November 2017

Zitat von Febas

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.

Febas · 29. November 2017

Zitat von aziegler

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

kk · 29. November 2017

Zitat von Febas

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).

Febas · 29. November 2017

Zitat von kk

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!

clickpress · 10. Februar 2018

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.

aziegler · 10. Februar 2018

Zitat von clickpress

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

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

clickpress · 10. Februar 2018

Zitat von aziegler

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.

aziegler · 10. Februar 2018

meine eigentliche Frage ist immer noch unbeantwortet.
Ich zitiere mal:

Zitat

als CLI ist z.B PHP 7.1 oder 7.2 eingebunden.

was heißt das? wo wird eine PHP-CLI wie genau "eingebunden"?

antondollmaier · 11. Februar 2018

Zitat von clickpress

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.

clickpress · 11. Februar 2018

Zitat von antondollmaier

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).

clickpress · 11. Februar 2018

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:

Bash

#!/bin/sh
#  _    _          ___           __ _     (R)
# | |  (_)_ _____ / __|___ _ _  / _(_)__ _
# | |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
# |____|_|\_/\___|\___\___/_||_|_| |_\__, |
#                                    |___/
# Copyright (c) 2009-2017 Keppler IT GmbH.
# ----------------------------------------------------------------------------
# common/tools/cron.php.sh
# $Id: cron.php.sh 4773 2017-11-29 08:39:13Z kk $
#
# Shell script to remove expired PHP session files (via cron)
# Inspired by Debian's /usr/lib/php5/maxlifetime and /etc/cron.d/php5
# ----------------------------------------------------------------------------


set -e


. /etc/liveconfig/sysconfig || exit 0


# Default expire time: 1440 seconds = 24 minutes
EXPIRE=1440


if which php >/dev/null 2>&1 && [ -d '$LC_WEBROOT' ]; then
  # detect version of default PHP-CLI binary:
  PHPVERSION=`php -r 'echo phpversion();' | sed -e 's/\.//g' | cut -c1-2`
  if [ '$PHPVERSION' = '70' ]; then
    PHPVERSION="7"
  fi


  PHPMAJOR=`echo $PHPVERSION | cut -c1`


  for cust in $LC_WEBROOT/*; do
  [ -d '$cust' -a -d '$cust/tmp' ] || continue
      # get session.gc_maxlifetime
      max=$EXPIRE
      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
        cur=$(php -c "$cust/.php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')
      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");')
      fi
      [ -z '$cur' ] && cur=0
      [ '$cur' -gt '$max' ] && max=$cur
      max=$(($max/60))
      find "$cust/tmp" -type f -cmin +$max -regex ".*/sess_[a-z0-9]*" -delete
    done
fi


exit 0

Alles anzeigen

antondollmaier · 11. Februar 2018

Um die Ausgangsfrage zu beantworten:

Zitat von clickpress

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.

clickpress · 11. Februar 2018

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

TCRserver · 12. Februar 2018

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

clickpress · 12. Februar 2018

Zitat von TCRserver

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.

TCRserver · 12. Februar 2018

Zitat von clickpress

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.

Doch klar, einbinden von IonCube erfolgt immer über LC.
In dem Bsp. ist IonCube in den PHP Einstellungen eingebunden für PHP >= 5.6 und <5.7

kk · 12. Februar 2018

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.

clickpress · 12. Februar 2018

Zitat von kk

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.

cron.php.sh verwendet alte php.ini

Jetzt mitmachen!

Benutzer online in diesem Thema