Hallo … der System-Cron läuft unter dem User root. DAs hat zur Folge, daß die einzelnen Shop-CronJobs ebenfalls unter dem User root ausgeführt werden und der Cache (root)-Einträge enthält, die später zu “Permission Denied” Fehlern führen: [2014-08-14 10:19:28] core.ERROR: exception ‘UnexpectedValueException’ with message ‘RecursiveDirectoryIterator::__construct(/var/www/vhosts/shop.trimension.de/cache/templates/frontend_emotion_trimension_de_DE_1/1c): failed to open dir: Permission denied’ in /var/www/vhosts/shop.trimension.de/engine/Shopware/Components/CacheManager.php:373 Stack trace:… Wenn ich den System-Cron unter www-data laufen lasse, werden die Shopware CronJobs nicht ausgeführt. Auszug aus cron.log (www-data) CMD (cd /var/www/vhosts/shop.trimension.de && /usr/local/bin/php shopware.php /backend/cron Gibt es dafür eine Lösung ?
So sollte es klappen su -c "crontab -e" www-data @hourly cd verzeichnis && /usr/local/bin/php shopware.php /backend/cron \>/dev/null 2\>&1 @daily cd verzeichnis && /usr/local/bin/php shopware.php /backend/Newsletter/cron \>/dev/null 2\>&1 @daily cd verzeichnis && /usr/local/bin/php exchangerate.php \>/dev/null 2\>&1
das ist leider nicht die Lösung. wie ich bereits schrieb, werden die Shopware-CronJobs nicht ausgeführt, wenn sie durch den System-Cron getriggert werden, der nicht unter root läuft. Wenn ich das Kommando in der www-data-crontab eintrage wird das kommando vom System korrekt und zur richtigen Zeit abgesetzt. Aber die Shopware CronJobs, die dadurch angestoßen werden sollten werden eben nicht angestoßen. Das funktioniert NUR, wenn das Kommando von einem System-Cron unter root angestoßen wird. Unter welchem User müssen die Cron-JObs laufen, damit die Shopware Crons ausgeführt werden und der Cache nicht kaputt geht ? Warum laufen die SW-Crons nicht an, wenn sie durch den www-data-cron getriggert werden ? ggf. kann man Shopware vielleicht dazu bringen, die Cache-Einträge so zu schreiben, daß sie für alle schreib- und lesbar sind (666) ?! Jemand ne Idee ?
Der Cronjob wird unter dem User laufen gelassen unter dem auch der Shop bzw. der Webserver läuft. Wenn das bei euch www-data ist, dann sollte das so auch gehen. Was passiert denn wenn du den Befehl in die Console eintippst, wie sind die Rechte des Users?
wenn ich den Befehl von der Console unter dem User www-data (user unter dem der Apache läuft) eingebe, werden die SW-Jobs korrekt gestartet. Nur wenn der gleiche Befehl aus der Crontab abgesetzt wird, dann tuts nix… sehr komisch… Der User www-data hat die Standard-Rechte des Systems (umask 0022). Bleibt zu forschen, was anders ist, wenn der Befehl aus Crontab gestartet wird.
Beispiel: Aug 11 02:59:01 s17333484 /USR/SBIN/CRON[8426]: (root) CMD (cd /var/www/vhosts/shop.trimension.de && /usr/local/bin/php shopware.php /backend/cron >>/var/log/cron.log) Processing Aufräumen Processing Lagerbestand Warnung Processing eMail-Benachrichtigung Processing Topseller Refresh Processing Similar shown article refresh Processing Refresh search index Processing TrimensionSepaExport aber… Aug 15 22:30:01 s17333484 /USR/SBIN/CRON[29159]: (www-data) CMD (cd /var/www/vhosts/shop.trimension.de && /usr/local/bin/php shopware.php /backend/cron >>/var/log/cron.log
Ok mal ein Schuss ins Blaue. Du führst den Cronjob als www-data aus und erstellst eine neue Datei „/var/log/cron.log“, das geht wahrscheinlich aus dem Grund schief weil www-data keine Schreibrechte in „/var/log/“ hat.
Probier mal zum testen:
cd /var/www/vhosts/shop.trimension.de && /usr/local/bin/php shopware.php /backend/cron >> /var/www/vhosts/shop.trimension.de/cron.log
Hallo… Der Schuß ins Blaue war ein Volltreffer… Guter Tip… Vielen Dank…