Shopware CLI Befehle Fehlermeldung in der Shell

  • Ja Hallo, ich bin der Neue :)


    Wir haben ein Webhosting 8000 gebucht letzte Woche und dort einen Shopware installiert, übertragen. Uns geht es da um die Performance, Geschwindigkeit, und dazu wollen wir natürlich CLI Befehle einsetzen, zB um cache aufzuwärmen, etc.. Aber das geht leider schief. Wenns nicht klappt, bzw. wir keine Lösungen finden, dann müssten wir eine Alternative suchen...


    Aktuell will ich über die Shell diesen befehl aufrufen:

    /pfad/bin/console sw:plugin:list --help


    Ich will damit die Funktionalität grundsätztlich prüfen.


    Das Ergebnis bzw. die Rückmeldung des Systems ist:

    php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory


    Damit kann ich so nichts wirklich anfangen, es übersteigt momentan meine Möglichkeiten. Ich vermute, dass ich keine libraries selber installieren kann, lasse mich aber gerne belehren an dieser Stelle. Ich würde mich sehr freuen wenn es dafür eine Lösung gäbe, die CLI Befehle für mich nutzbar wären.


    Hat jemand dazu Empfehlungen, Hinweise, Ideen?


    Danke vielmals im Voraus.


    Grüße


    Markus

  • Der Webserver und die CLI können auf unterschiedlichen PHP-Default Versionen haben. Du nutzt bei der CLI die gleiche Version wie bei Webserver?

    "Security is like an onion - the more you dig in the more you want to cry"

  • Ich bin nicht sicher welche Möglichkeiten ich habe. Es ist ein Webhosting 8000 Paket, kein eigenständiger Server. In der bin/console Datei im Shopware kann ich in der ersten Zeile scheinbar modifizieren:

    #!/usr/bin/env php

    zB in

    #!/usr/local/php71/bin/php


    Und damit bekomme ich eine bessere Ausgabe!

    Ah, super, vielen Dank für die Hilfe, für die Inspiration :)


    Grüße


    Markus

  • Kenne Shopware nicht, aber ich denke die Datei könnte bei Updates überschrieben werden. Probier ansonsten die Datei direkt so auszuführen:

    /usr/local/php71/bin/php /pfad/bin/console sw:plugin:list --help 

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

    • Offizieller Beitrag

    Das Ergebnis bzw. die Rückmeldung des Systems ist:

    php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory

    Guten Tag,


    der Fehler sollte nun in jedem Fall behoben sein.

  • Eine Kundin von mir die ich gerade euch vermittelt habe, hat in ihren Account gerade das gleiche Problem


    Bitte nicht in einer Testumgebung testen sondern direkt auf den Server!

    Ticketnummer: NC#2019082110010033

  • Nur "php" ist leider nicht eindeutig, da es ja verschiedene installierte PHP-Versionen auf dem System gibt. Die Version, die "php" auf der Konsole aufruft ist nicht zwingend die Version, die im Panel eingestellt ist. Am besten sollten hier also absolute Pfade verwendet werden. Deshalb der Einwand von vmk . "which php" liefert dir den kompletten Pfad zurück.

    In jedem Fall ist das ein Fehler, der von Netcup gefixt werden muss und dafür ist dein Ticket der richtige Weg. Hier im User-zu-User Forum können wir dir nur raten statt "php" eben "/usr/local/php71/bin/php" (entsprechend deiner gewünschten PHP-Version anpassen) zu nutzen.

  • Nur "php" ist leider nicht eindeutig, da es ja verschiedene installierte PHP-Versionen auf dem System gibt. Die Version, die "php" auf der Konsole aufruft ist nicht zwingend die Version, die im Panel eingestellt ist. Am besten sollten hier also absolute Pfade verwendet werden. Deshalb der Einwand von vmk . "which php" liefert dir den kompletten Pfad zurück.

    which php gibt auf all meinen Webhostings den Pfad "/usr/bin/php" zurück. Und das wiederum ist dann aber ein symbolischer Link auf die eigentliche php-Binary, also z.B. "/usr/local/php71/bin/php" oder eine der anderen Versionen. Welche das jeweils ist, da bin ich mir nicht sicher. Ich dachte eine Zeit lang, es sei immer die für die Systemdomain eingestellte Version, aber ich glaube ich hatte mal irgendwo ein Gegenbeispiel. Letztlich ist es egal, ich gebe sowieso immer den kompletten Pfad an.

  • Hallo,

    ich habe nun den gleichen Fehler wie hier erwähnt. Ich möchte php ausführen und gebe hierfür den direkten Pfad an ("/usr/local/php72/bin/").

    Ich bekomme jedoch folgenden Fehler:


    php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory


    Wie wurde der Fehler denn gelöst? Brauche ich hierfür die Hilfe vom Support?


    Freundliche Grüße und vielen Dank schon mal im Voraus,

    der Fuchs

  • Hallo Bensen, tatsächlich nutze ich php 7.2 und habe so auch den Webserver eingestellt, die php files sind auch alle vorhanden.

    Ich bin auch direkt in den Ordner gegangen und habe versucht ./php auszuführen, jedoch besteht der gleiche Fehler.

  • Hallo Bensen, tatsächlich nutze ich php 7.2 und habe so auch den Webserver eingestellt, die php files sind auch alle vorhanden.

    Ich bin auch direkt in den Ordner gegangen und habe versucht ./php auszuführen, jedoch besteht der gleiche Fehler.

    Wenn der Webserver und somit auch Shopware mit PHP7.2 laufen, sollte man in der Schell auch mit 7.2 arbeiten (/usr/local/php72/bin/php).


    Wie und mit welchen Befehl rufst du Shopware den genau auf, wodurch der von dir oben genannte Fehler Auftritt?

  • Ich rufe lediglich php -v auf.

    Der eigentliche Plan, ist es ein Composer update mit einer lokalen composer.phar auszuführen, da mein Projekt eigentlich für PHP 7.3 geschrieben wurde.

    Ich komme bereits von einer Reise aus Fehlern, provoziert durch die Zusammenarbeit von Apache und nginx.

    Long story short: Ich kann CGI nicht benutzen sondern brauche FPM. Das geht jedoch nur mit PHP 7.2.

  • Hallo Weizenfuchs,


    wenn dieser Fehler schon bei einem "php -v" auftritt, solltest du dies am besten direkt dem Netcup Support melden (zusammen mit der Webhosting ID). Das klingt ganz nach dem Fehler, den schon andere hier hatten. Da kann dann bzw. muss der Support tätig werden.