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

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.

Shaughn
la source

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=always

et 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

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

Réponses: