Le titre résume assez bien. Y a-t-il une différence entre le fichier shell et le fichier php pour le cron Magento?
S'il y a une différence, y a-t-il une raison pour exécuter l'un au lieu de l'autre?
magento-1.9
cron
Chris Morris
la source
la source
Réponses:
Le cron.sh pointe vers le fichier cron.php, vous devez donc pointer votre tâche cronjob vers le fichier .sh.
Fondamentalement, à l'intérieur du fichier PHP se trouve toute la logique pour que le cron récupère les travaux de Magento et le fichier sh appelle le fichier PHP.
la source
cron.sh
fichier est configuré pour vérifier qu'aucun processus cron ne s'exécute dans Magento avant d'en démarrer un nouveau. Utilisez-le toujours comme déclencheur. Dans certains schémas de sécurité avec WHM / cPanel, il se peut que vous ne soyez pas autorisé à exécuter des scripts shell en tant que tâches cron et que vous exécutez ensuite directement àcron.php
partir de crontab.shell_exec
désactivé dans WHM / cPanel, mais cela ne signifie pas qu'il est signalé comme désactivé lors descron.php
vérificationsini_get('disable_functions')
. Donc cron essaie de s'exécuter, voitshell_exec
comme non désactivé, essaie de l'utiliser et échoue car il est désactivé. haussement d'épaulesVous devriez utiliser
cron.sh
, c.-à-d.En fonction de votre environnement,
cron.sh
exécutecron.php
qui s'exécute,cron.sh
qui s'exécutecron.php
. Il est conçu pour empêcher le cron de Magento d'exécuter des tâches plusieurs fois ou de générer trop de processus qui se chevauchent.La première fois qu'il est exécuté,
cron.sh
vérifiera les processus en cours d'exécution pour voir s'ilcron.php
est déjà en cours d'exécution (sans aucun argument). Sinon, il s'exécuteraLe
cron.php
premier run (et selon que votre système d' exploitation / supports de l' héberger) il va produire àcron.sh
nouveau , deux fois, mais cette fois -ci passer des arguments:De retour
cron.sh
pour la deuxième fois, il vérifiera à nouveau si cron fonctionne avec les paramètres spécifiés. Sinon, il le renverracron.php
avecdefault
oualways
.Et
cron.php
pour la dernière fois, cela déclenchera Magento pour exécuterdefault
des tâches cron (à peu près toutes), ainsi quealways
des tâches cron (commeenterprise_refresh_index
). En les séparant en deux processus, cela réduit le risque qu'un travail de longue durée ne bloque les autres.la source
cron.sh
Utiliser
/bin/sh
pour traiter ce scriptDéfinissez une constante
CRONSCRIPT
avec le fichier à appeler. $ 1 est le premier argument, commecron.sh /whatever/path/cron.php
définir une autre constante, ici vous pouvez passer
always
oudefault
explicitement.cron n'a pas de variables d'environnement, donc vous ne pouvez pas simplement appeler
php
.which
vous dit, où le binaire php est vivant, très probablement dans/bin/php
$0
est le fichier lui-même, comme__FILE__
dans phpJe ne sais pas exactement comment cela fonctionne, mais ce qu'il fait: appeler
cron.php
avecphp
.cron.php
Comme déjà dit, cron n'a pas de répertoire de travail ni aucune autre variable d'environnement, donc le répertoire de travail est défini.
Si vous appelez cron.php par curl ou quelque chose, les noms de fichiers sont fixes?
Définissez umask, qui définit avec quelles autorisations les nouveaux fichiers sont créés - zéro autorisation, personne n'est autorisé à faire quoi que ce soit.
Assurez-vous que toutes les fonctions sont autorisées et nécessaires.
ensemble
$cronmode
si cronmode n'est pas défini, nous appelons
cron.sh
avec les deux modesEt puis magento fait enfin son travail:
charger des observateurs d'événements et les ajouter au pool d'observateurs
si
shell_exec
est désactivé, répartissez les événements\Aoe_Scheduler_Model_Observer::dispatchAlways
et\Mage_Cron_Model_Observer::dispatch
exécutez les tâches cron.la source