Probleme mit dem ZendGuardLoader / Apache reload führt Apache ins Nirvana

  • Okay, dass ist nicht wirklich ein Problem mit bzw an LiveConfig. Da es aber grundsätlich nicht selten vorkommt, dass ZendGuardLoader nötig ist und ich gestern den ganzen Tag mit der Fehlersuche verbracht habe, möchte ich das hier einmal Posten.


    Hat außer mir denn niemand den ZendGuardLoader mit PHP5.3 oder PHP5.4 auf LiveConfig-Servern laufen oder trifft es tatsächlich nur mich?


    Das Problem habe ich hier im gSales-Forum beschrieben.


    Könnt Ihr das bitte auch mal ausprobieren? So wie es für mich derzeit aussieht, kann man auf LiveConfig-Servern/Clients seinen Kunden kein ZendGuardLoader anbieten - das liegt aber definitiv NICHT an LiveConfig!


    Schönes Wochenende,


    Oskar

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Hallo,


    ich habe eben mal auf einen Kundenserver bei uns geschaut, bei dem wir vor einiger Weile den ZendGuardLoader aufgesetzt hatten. Dort läuft alles völlig problemfrei, auch nach einem Apache-Reload.
    Es handelt sich um einen dedizierten Server mit Debian Squeeze (AMD64), aktuellem PHP (via suPHP und FastCGI).
    Der ZendGuardLoader ist über eine Datei namens /etc/php5/conf.d/zend.ini eingebunden:

    Code
    zend_extension=/usr/lib/php5/20090626/ZendGuardLoader.so


    MD5-Prüfsumme des Zend-Loaders ist abde7aab4ddfc99755b548e865071253 (aus dem Paket ZendGuardLoader-php-5.3-linux-glibc23-x86_64.tar.gz vom 04.03.2013).


    Wie nutzen Sie PHP? Mit suPHP/FastCGI oder als mod_php?


    Mit einer OpenVZ-Umgebung kann ich das auch mal durchtesten, die haben wir aber derzeit nur unter CentOS 6.4 verfügbar.


    Viele Grüße


    -Klaus Keppler

  • Hallo Herr Keppler,


    exakt so wie in Ihrem Beispiel, nur in meinem Fall ein anderer Pfad zum ZendGuardLoader.so und FastCGI, als mich das Problem zum ersten Mal traf.


    Inzwischen habe ich es in allen Kombinationen aus Squeeze, Wheezy, mit und ohne FastCGI, suPHP und mod_php auf verschiedenen Maschinen, Original-PHP aus Debian oder aktuelle aus dotdeb.org und mit absolut sauberen Apache-Installationen probiert. Die Einzige Konstante ist, dass es sich dabei immer um OpenVZ-Container handelt und ich die Kernel aus den OpenVZ-Quellen nutze und nichtg die veralteten Debian-Kernel.


    Ich werde das gleich mal stumpf auf meinem Notebook unter Linux Mint probieren.


    Viele Grüße,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Die können ja ggf mal "strace" installieren, damit dann mal Apache im Vordergrund starten, und dann mal ein SIGHUP an den Apache-Prozess senden (für den Reload). Ist etwas "Hardcore" ;) aber hilft vielleicht bei der Lokalisierung des Problems.


    viele Grüße


    Klaus Keppler

  • Inzwischen bin ich ziemlich sicher, dass es eine Unverträglichkeit zwischen ZendGuardLoader und dem RHEL6-Kernel aus den OpenVZ-Quellen gibt.


    Was ich für gewöhnlich nicht mache, nämlich den Apache auf dem Root-Server ohne Virtuelle Instanz selbst zu installieren, bringt das gleiche Problem. Nur, dass hier der Apache nicht hängen bleibt, sondern sich mit einem SegFault einfach verabschiedet. Auf Hardware-Level ist er also einfach neu zu starten und er läuft dann bis zum nächsten reload.


    In der VE kann der Apache auch neu gestartet werden, wenn vorher ein killall -KILL apache2 abgesetzt wird.


    ein php5 -v ergibt sowohl auf der Hardware-Node als auch in der VE:


    Code
    PHP 5.4.4-14 (cli) (built: Mar  4 2013 14:08:43)
    Copyright (c) 1997-2012 The PHP Group
    Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
        with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies
    Segmentation fault


    Also bereits hier ein SegFault.


    Ich gebe für's Wochenende auf. Ich werde es dann am Montag nochmal mit strace versuchen. Außerdem noch richtig pervers: Ich werde unter VMWare ein Debian Installieren und hier einmal mit dem Kernel aus Debian und anschließend nochmal mit dem Kernel von OpenVZ probieren, ob es zum selben Ergebnis kommt.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Ich kann den SegFault nicht bestätigen.


    Host: Debian 6.0 x64
    OpenVZ Kernel: 2.6.32-042stab078.10 (rpm mit alien konvertiert)


    VM: Ubuntu 12.04 x32
    -------------------
    * Reloading web server config apache2


    php5 -v


    PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:34:31)
    Copyright (c) 1997-2012 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
    with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH

  • Eventuell ist auch die Reihenfolge in der IonCube Loader und ZendGuardLoader geladen wird falsch ?


    Code
    zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.3.so
    zend_extension = /usr/local/lib/Zend/ZendGuardLoader.so
    zend_optimizer.optimization_level = 15
  • Dann gibt es aber nen PHP Error und kein SegFault:


    PHP Fatal error: [ionCube Loader] The Loader must appear as the first entry in the php.ini file in Unknown on line 0


    Apache hängt sich auf mit einem Single Prozess und 100% CPU

  • Dankeschön! Also der ionCube kann's nicht sein, weil er garnicht geladen wird. Das Problem tritt ja schon auf, wenn nach der Grundinstallation nur der ZendGuardLoader geladen wird. Dann gibt's, wie problay.de geschrieben hat, den 100%-Apache-Prozess. Allerdings nur in der VE, nicht auf der Hardware, da steigt der Apache einfach aus. Sowohl in der VE als auch auf der Node selbst mit einem Segmentation Fault im Apache Error-Log.


    Was ich jetzt sehe, ist dass problay.de einen Testing-Kernel nutzt während ich doch etwas konservativer den letzten Stable nutze. Auch ich hab' den mit alien konvertiert.


    Aber das ist ein Ansatz. Während ich gerade im Hintergrund auf einer HyperV ein Debian 7 installiere um den Test nochmal zu machen, ziehe ich mir mal den letzten Testing-Kernel auf die echte Maschine und probier's mal damit. Aber ich werde wohl gleich vom Stuhl kippen... morgen mehr.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Also, frisch installiertes Debian 7 - nur der Apache, PHP5 und ZendGuradLoader als HyperV-Instanz - gleiches Problem.
    Diese Installation mit dem letzten Testing-Kernel 2.6.32-042stab078.22 - gleiches Problem.


    Verzweifeln! ... Eingebung!


    Ich habe auf dem scharfen Server, auf dem das Problem zum ersten Mal von mir erkannt wurde, mod_php entfernt, da es ohnehin nicht genutzt wird und alles über fastcgi läuft. Problem verschwunden, gSales läuft, keine sporadischen SegFaults im Apache-Error-Log!


    Nur eines bleibt:


    :/# php5 -v
    PHP 5.3.26-1~dotdeb.0 with Suhosin-Patch (cli) (built: Jun 9 2013 03:35:34)
    Copyright (c) 1997-2013 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
    with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
    with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH
    Segmentation fault


    Ich weiß noch nicht, ob mich das nun sorgen soll oder nicht. Ich lasse es jetzt erst mal so laufen.


    Gute Nacht!

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Ja schon. Allerdings habe ich den Test hier lokal mit Debian 7 auf der HyperVM mit dem Net-Install-Image von Debian installiert. Dürfte auf's gleiche rauskommen. Probieren werde ich das aber auch nochmal.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Hallo,


    ich muss das Thema mal kurz aufwärmen - in Bezug auf die Version des Zend Guard Loaders.


    Auf zend.com finde ich keine Version mit der von Herrn Keppler angegebenen md5 Checksumme ...... auch bekomme ich als Ausgabe von php -v lediglich Version 3.3 -->


    Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with the ionCube PHP Loader v4.4.0, Copyright (c) 2002-2013, by ionCube Ltd., and
    with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies
    with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH



    Und ich habe ein Problem mit einer Software, die explizit nach Zend Guard 5.5 unter PHP 5.3 verlangt - die Installation verlief problemlos, aber nun bekomme ich lediglich "Internal Server Error" -> 500 er Fehler.
    In den LOG´s steht tatsächlich absolut nichts dazu - also weder in der error.log, access.log etc. - nix, null.

  • Hallo Sven,
    die Software kann das nicht fordern, da das nicht geht.
    Zend Optimizer 3.3 ist für PHP 5.2
    Zend Guard Loader 5.5 ist für PHP 5.3
    Zend Guard Loader 6.0 ist für PHP 5.4


    Eine andere Kombination ist nicht vorgesehen und nicht möglich.


    Sie verwenden übrigens auch eine veraltete ionCube Version, aktuell ist 4.7.5 für alle PHP-Versionen.

  • Hallo aziegler,


    vielleicht überlesen, was ich schrieb --> "die explizit nach Zend Guard 5.5 unter PHP 5.3 verlangt" ......damit meinte ich natürlich Zend Guard Loader 5.5 unter PHP5.3


    Welche Version für PHP5.2, 5.3, 5.4 nötig ist, ist mir geläufig.
    Das war ja aber auch nicht meine Frage.
    Mittlerweile habe ich aber auch rausbekommen, dass Zend Guard Loader in Version 5.5 und 6.0 auch noch 3.3 ausgibt.


    Den ionCube vernachlässige ich immer, weil ich den eigentlich nicht brauch (ja, ich weiß - man sollte trotzdem aktuell halten bzw. deaktivieren).

Jetzt mitmachen!

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