Startseite » Forum » LiveConfig-Foren (deutsch) » Fehler und Problembehebung » cron.php.sh verwendet alte php.ini
Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 11 bis 20 von 32
  1. #11
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    704
    Zitat Zitat von clickpress Beitrag anzeigen
    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.

    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.

  2. #12
    Benutzer
    Registriert seit
    20.09.2012
    Beiträge
    79
    Zitat Zitat von antondollmaier Beitrag anzeigen
    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).
    Geändert von clickpress (11.02.2018 um 00:24 Uhr)

  3. #13
    Benutzer
    Registriert seit
    20.09.2012
    Beiträge
    79
    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:
    Code:
    #!/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
    Geändert von clickpress (11.02.2018 um 01:06 Uhr)

  4. #14
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    704
    Um die Ausgangsfrage zu beantworten:

    Zitat Zitat von clickpress Beitrag anzeigen
    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.

  5. #15
    Benutzer
    Registriert seit
    20.09.2012
    Beiträge
    79
    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
    Geändert von clickpress (12.02.2018 um 00:02 Uhr)

  6. #16
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    107
    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
    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.
    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
    Geändert von TCRserver (12.02.2018 um 08:45 Uhr)

  7. #17
    Benutzer
    Registriert seit
    20.09.2012
    Beiträge
    79
    Zitat Zitat von TCRserver Beitrag anzeigen

    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.

  8. #18
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    107
    Zitat Zitat von clickpress Beitrag anzeigen
    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

  9. #19
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.284
    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.

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

Lesezeichen

Berechtigungen

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