Startseite » Forum » LiveConfig-Foren (deutsch) » Fehler und Problembehebung » cron.php.sh verwendet alte php.ini
Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 32
  1. #1
    Benutzer
    Registriert seit
    17.12.2013
    Beiträge
    53

    Frage 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?

  2. #2
    Benutzer
    Registriert seit
    17.02.2011
    Beiträge
    64

    Beitrag

    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..
    Geändert von Febas (29.11.2017 um 08:17 Uhr)

  3. #3
    Erfahrener Benutzer
    Registriert seit
    02.04.2012
    Beiträge
    633
    Zitat Zitat von Febas Beitrag anzeigen
    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.

  4. #4
    Benutzer
    Registriert seit
    17.02.2011
    Beiträge
    64
    Zitat Zitat von aziegler Beitrag anzeigen
    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

  5. #5
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.268
    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).

  6. #6
    Benutzer
    Registriert seit
    17.02.2011
    Beiträge
    64
    Zitat Zitat von kk Beitrag anzeigen
    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!
    Webhosting mit Febas: Leistungsstark, einfach, günstig!

  7. #7
    Benutzer
    Registriert seit
    20.09.2012
    Beiträge
    79
    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.

  8. #8
    Erfahrener Benutzer
    Registriert seit
    02.04.2012
    Beiträge
    633
    Zitat Zitat von clickpress Beitrag anzeigen
    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!

  9. #9
    Benutzer
    Registriert seit
    20.09.2012
    Beiträge
    79
    Zitat Zitat von aziegler Beitrag anzeigen
    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.

  10. #10
    Erfahrener Benutzer
    Registriert seit
    02.04.2012
    Beiträge
    633
    meine eigentliche Frage ist immer noch unbeantwortet.
    Ich zitiere mal:
    als CLI ist z.B PHP 7.1 oder 7.2 eingebunden.
    was heißt das? wo wird eine PHP-CLI wie genau "eingebunden"?

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •