Hallo zusammen,
wenn ich den Befehl sw:generate:attributes ausführen will erhalte ich folgende Fehlermeldung. Kann mir hierbei wer helfen? Woran liegt das, bzw. was muss ich ändern? Vielen Dank.
../httpdocs/shopware$ bin/console sw:generate:attributes
WARNING! Could not connect to database. Message from SQL Server: could not find driver in ../httpdocs/shopware/engine/Shopware/Components/DependencyInjection/Bridge/Db.php
[Symfony\Component\DependencyInjection\Exception\RuntimeException]
You have requested a synthetic service ("db_connection"). The DIC does not know how to construct this service.
sw:generate:attributes
Hast Du einen regulären SSH-Account oder evtl. einen, der in einem “Chroot” liegt und entsprechend eingeschränkt ist und nicht auf alle Tools zugreifen kann? Ggf. kann Dir Dein Hoster eine entsprechende Auskunft geben.
Timme Hosting - schnelles nginx-Hosting
www.timmehosting.de
Ich habe einen vServer und der SSH-Zugriff ist auf /bin/bash (chrooted).
Laut meinem Hoster sollte alles in Ordnung sein. Leider weiß ich nicht mehr weiter.
Und es betrifft mehrere Befehle, z.B.:
- sw:generate:attributes
- sw:cron:list
- sw:plugin:config:list
- sw:plugin:refresh
- sw:thumbnail:cleanup
- sw:warm:http:cache
Funktionieren tut wiederum z.B.:
Wenn ich aber z.B. den Cronjob “cd /httpdocs/shopware/ && /usr/bin/env TERM=xterm /usr/bin/php bin/console sw:warm:http:cache” ausführen lasse, klappt das ohne Probleme.
Der Shopware eigene Cronjob “Shopware_CronJob_ClearHttpCache” hat anscheinend aber wiederum Probleme laut den Protokollen:
mod_fcgid: stderr: PHP Warning: unlink(/var/www/vhosts/werbeartikel-welt.com/httpdocs/shopware/var/cache/production_201607131117/html/md/cc/91/8635cd7ddbeb067aacb20279598b483a54fcf8b9ce1e553cee32382f3f8f): No such file or directory in /var/www/vhosts/werbeartikel-welt.com/httpdocs/shopware/engine/Shopware/Components/HttpCache/Store.php on line 104
Ich bin leider vollkommen ratlos. Wäre schön wenn mir hier jemand helfen könnte.
Danke schön.
Ich habe den Titel mal noch etwas treffender formuliert und möchte das Thema gern nochmal aufleben lassen…
Ich muss die Shell auf „/bin/bash“ umstellen, um ein Perl-Skript ausführen zu können.
Wenn ich das aber tue, funktioniert folgender Cronjob-Aufruf nicht mehr:
cd httpdocs/shopware/ && /usr/bin/env TERM=xterm /usr/bin/php bin/console sw:warm:http:cache
Ich erhalte die folgende Fehlermeldung:
WARNING! Could not connect to database. Message from SQL Server: could not find driver in /var/www/vhosts/werbeartikel-welt.com/httpdocs/shopware/engine/Shopware/Components/DependencyInjection/Bridge/Db.php
[Symfony\Component\DependencyInjection\Exception\RuntimeException]
You have requested a synthetic service ("db_connection"). The DIC does not know how to construct this service.
sw:warm:http:cache []
Solange die Shell auf „/bin/bash (chrooted)“ gestellt ist, funktioniert alles wunderbar.
Mein Hoster sagt hier liegt möglicherweise ein Problem bei Shopware vor (es handelt sich wohl um ein Problem mit der Synfony Komponente, die auch Shopware verwendet), vielleicht kann das wer bestätigen?
Möglicherweise ist die Ursache die PHP Version. Serverseitig läuft PHP7 - bei Verwendung der vollwertigen Bash-Shell entspricht /usr/bin/php der PHP7 Version. Bei Verwendung der chroot Shell kommt PHP 5.6 zum Einsatz.
Wie oben erwähnt betrifft es prinzipiell auch nicht nur sw:warm:http:cache, sondern mehrere Befehle.
Vielen lieben Dank.
Grüß, Manuel
Hallo,
Möchte das Thema nochmals aufgreifen. Habe hier bei folgender Konstellation das gleiche Problem :
- PHP 7.013
- Plugin, dass via CLI Artikelaten über die Articleresource mittels batch() importiert
Nach ca. 2.500 erfolgreich importierten Artikel bricht der Import mit folgender Exception ab:
[Symfony\Component\DependencyInjection\Exception\RuntimeException]
You have requested a synthetic service (“db_connection”). The DIC does not know how to construct this service.
Und das während der Importer läuft, ohne jegliche weitere Exception.
Liebe Grüße
Die Ursache ist gefunden:
Kommt es bei der Anlage eines Articles zu einer Exception, wird der DIC in der batch() Methode der Article Resource resetet. Das ist kein Problem, wann man die API auf dem “klassischen” Weg via HTTP verwendet, da für jeden Request ein neuer Stack hochgefahren wird und der DIC auch entsprechend neu aufgebaut wird.
Geht man aber den schnelleren (internen) Weg über die Resource, wird der DIC resetet und anschließen nicht mehr neu aufgebaut, da es bei jedem weiteren Aufruf ja noch immer der gleiche Request ist.
D.h. man muss herausfinden, warum der EM nicht mehr existiert, dann sollte auch das Problem mit dem DIC gelöst sein.