Quel script cron est préférable d'exécuter? cron.php ou cron.sh


27

Magento fournit deux scripts cron dans son répertoire racine, cron.php et cron.sh.

Laquelle est la meilleure à exécuter et pourquoi?

Réponses:


31

Il serait préférable d'exécuter cron.sh

Depuis Magento EE 1.13.x et CE 1.8.x, la mécanique du cron a changé où Magento a introduit une nouvelle fonction de mode de planification.

Il existe 2 modes disponibles: 1. par défaut - exécute les crons planifiés. 2. toujours - Comme son nom l'indique, ces tâches seront exécutées sans condition chaque fois que cron est déclenché et n'ont pas besoin de planifications explicitement définies.

Fondamentalement, cron.php est appelé sans aucun paramètre utilise shell_exec pour exécuter deux processus de cron.sh. Chacun avec un paramètre différent («par défaut» ou «toujours»). Cron.sh transmet à son tour ce paramètre à cron.php qui exécute ensuite le cron. En interne, Magento utilise son infrastructure d'événements pour traiter les deux modes en répartissant les événements avec les noms «par défaut» et «toujours». Mage_Cron implémente ensuite deux méthodes d'observation.

En regardant cron.php, vous remarquerez l'utilisation de la fonction PHP shell_exec. En plus d'être un problème de sécurité, la fonction peut retourner NULL à la fois lorsqu'une erreur se produit ou que le programme ne produit aucune sortie. Il n'est pas possible de détecter les échecs d'exécution à l'aide de cette fonction. Cela signifie qu'à tout moment où votre script / code échoue en raison d'une erreur, les événements suivants se produisent: 1. Le cronjob devient obsolète, 2. Aucune erreur n'est enregistrée, 3. et personne ne sait que cela s'est produit.

Pour surmonter cela, les tâches cronjob suivantes doivent être ajoutées:

*/5 *   * * *   www-data /bin/sh /path/to/magento/cron.sh cron.php -m=default
*/5 *   * * *   www-data /bin/sh /path/to/magento/cron.sh cron.php -m=always

Cela garantira que les modes de processus seront toujours exécutés sans utiliser la fonction PHP de secours shell_exec et que le cron ne devienne pas périmé lorsqu'une exception est levée si une erreur se produit.


Je vais juste ajouter que l'exemple d'exemple de cron ci-dessus est assez générique. www-datachangerait pour tout utilisateur exécutant des processus de serveur Web. Il convient également de noter que pour de nombreuses configurations d'hébergement CPanel / WHM, shell_exec()va être désactivé.
pspahn

*/5 * * * * www-data /bin/sh /path/to/magento/cron.sh cron.php -m=default */5 * * * * www-data /bin/sh /path/to/magento/cron.sh cron.php -m=alwayset ces commandes donnent une erreur "commande non trouvée" par nupur walia
Amit Bera

Si vous obtenez cette erreur, vous devez vérifier 3 choses: 1) www-data est le bon utilisateur sur ce serveur qui peut exécuter ce processus, sinon changez-le en quel que soit l'utilisateur. 2) vérifiez l'emplacement de sh, exécutez donc "quel sh" et il devrait sortir l'emplacement, cela remplacera "/ bin / sh" s'il s'agit d'un chemin différent. 3) vérifiez enfin que le chemin vers cron.sh est bien correct.
Shaughn

@AmitBera J'obtenais le même message d'erreur et je ne pouvais pas le faire fonctionner avec www-data, root ou tout autre utilisateur. En fait, j'ai juste omis l'utilisateur et cela fonctionne maintenant, donc*/5 * * * * /bin/sh /path/to/magento/cron.sh cron.php -m=default
Michael

@Shaughn pouvez-vous expliquer à quoi sert le mode par défaut et toujours?
Rohan Hapani
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.