Magento 1.9.1 cron_schedule n'est pas choisi pour toujours


12

J'ai passé presque 3 jours et je ne peux pas comprendre et faire le Magento Cron pour traiter les tâches planifiées. J'utilise Magento 1.9.1.0 et j'ai récemment remarqué que les e-mails de commande sont désormais mis en file d'attente au lieu d'être envoyés instantanément. Je comprends la nécessité mais je ne peux pas faire le système pour choisir les files d'attente.

Voici ma vision pour Cronjob. entrez la description de l'image ici

Voici ma ligne de commande cronjob. entrez la description de l'image ici

Voici comment les tâches sont créées dans la table cron_schedule. entrez la description de l'image ici

Étant donné que les enregistrements sont créés dans la table cron_schedule, je pense que le Cron fonctionne une fois toutes les 5 minutes. Si je supprime manuellement ces enregistrements via PhpMyAdmin, les enregistrements sont créés automatiquement après un certain temps.

Mais l'état des tâches reste «en attente» et jamais terminé. Je ne sais pas si quelque chose ne va pas dans ma configuration ou si je manque quelque chose. Quelqu'un peut-il m'aider à exécuter la tâche planifiée à temps? Aussi pourquoi plusieurs enregistrements sont créés pour un code de travail?

Mise à jour

J'ai effacé la table entière et le cron a créé les travaux planifiés. Tous les travaux sont en attente et ne s'exécutent jamais, même en attendant plus de 60 minutes. Quelque chose ne va pas dans Magento 1.9.1

Mise à jour 11/02: Aujourd'hui, j'ai fait plus d'analyses sur le processus.

J'ai édité le cron.php comme ci-dessous

echo 'iam before mdefault 1';
shell_exec("/bin/sh $baseDir/cron.sh $fileName -mdefault 1 > /dev/null 2>&1 &");
echo 'iam before malways 1';
shell_exec("/bin/sh $baseDir/cron.sh $fileName -malways 1 > /dev/null 2>&1 &");
echo 'i returned success';

J'ai édité la classe Mage_Cron_Model_Observer comme ci-dessous

public function dispatch($observer) {
  echo 'iam inside dispath';

Ma compréhension était que lorsque le cron exécute le -mdefault, il devrait appeler la fonction de répartition et l'exécution se produira. Mais ce qui s'est passé était comme ci-dessous dans la sortie cron.

Content-type: text/html

iam before mdefault 1iam before malways 1i returned success

Cela signifie que la dépêche n'appelle pas du tout ...

Un autre essai

J'ai changé manuellement la variable $isShellDisabled = true;et j'ai changé celle ci-dessous dans cron.php.

if ($isShellDisabled) {
  echo 'before always';
  Mage::dispatchEvent('always');
  echo 'after always';
  Mage::dispatchEvent('default');
  echo 'after default';
} else {
  Mage::dispatchEvent($cronMode);
}

La sortie cron pour ce qui précède est comme ci-dessous

Content-type: text/html

before alwaysiam inside dispath alwaysafter always

Maintenant, il appelle le «dispatchAlways» mais pas le «dispatch»

Aucune des réponses ne m'aide. Il ne choisit jamais les tâches planifiées. C'est-à-dire lorsque le Cron s'exécute pour la première fois, il a réussi à créer les tâches dans le tableau. Mais il n'exécute jamais la tâche.


Que se passe-t-il lorsque vous exécutez cron.php à partir d'un navigateur Web? Ce sera une page vierge, mais je veux dire ce qui arrive à vos tâches cron?
seanbreeden

Essayez d'utiliser le script bash: */5 * * * * /bin/sh PATH_TO_PRODUCTION/cron.shsi disponible.
Phil Birnie

@seanbreeden, lorsque je lance via URL sur le navigateur, il affiche une page vierge. Rien n'est arrivé aux tâches .. J'ai mis à jour la question avec le nouvel ensemble de tâches créé ...
Malaiselvan

@PhilB, .sh ne fait aucune différence. C'est similaire, les tâches en attente sont en attente pour toujours, mais je suis sûr que le cron fonctionne toutes les 5 minutes.
Malaiselvan

as-tu essayé de vider la cron_scheduletable? Vérifiez si elle est remplie de nouvelles tâches après une heure environ
Sander Mangel

Réponses:


3

C'était la version PHP de Cron Jobs.

La version PHP a été définie correctement pour le site, c'est pourquoi il fonctionnait; cependant Cron Jobs s'exécutait sur le serveur natif PHP 5.3, c'est pourquoi j'obtenais les erreurs uniquement lors de l'exécution de Cron. J'ai mis à jour la version 5.5.

Commande Cron modifiée:

php /home/mydomainname/public_html/cron.php
to
php55 /home/mydomainname/public_html/cron.php

ou en hostgator:

/opt/php55/bin/php /home/mydomainname/public_html/cron.php

dans cron.php

$isShellDisabled = (stripos(PHP_OS, 'win') === false) ? $isShellDisabled : true;

Après cette ligne, ajoutez:

$isShellDisabled = true;

La mention d'exécuter cron.php dans une version PHP spécifique (ea-php70 dans mon cas) a résolu les problèmes que je rencontrais: exécutez php -vdans le terminal pour voir quelle version PHP le terminal utilise. Dans mon cas, c'était 5,6. J'ai donc dû forcer l'utilisation de PHP 7.0 en passant phpà ea-php70in crontab -e. Merci!
Daan van den Bergh

2

as-tu essayé de vider la cron_scheduletable? Vérifiez s'il est rempli de nouvelles tâches après environ une heure.

Vous pouvez également utiliser Aoe_Scheduler pour désactiver des tâches cron spécifiques. Vérifiez si un élément particulier peut provoquer une erreur qui interrompt toutes les autres tâches.

La façon dont les cronjobs Magento sont configurés une erreur fatale dans un script entraînera l'échec de l'exécution de toutes les tâches


Merci d'avoir répondu. L'erreur fatale est-elle capturée dans un journal? J'ai mis à jour quelques conclusions supplémentaires sur mon cas et mis à jour la même chose dans ma question.
Malaiselvan

@seanbreeden: Aujourd'hui, j'ai remarqué que lorsque je lance le Cron.php via un navigateur Web, cela fonctionne très bien en choisissant les horaires. Cela prouve qu'il n'y a aucune erreur fatale dans aucun des scripts. Une idée pourquoi le cron ne fonctionne pas via crontab?
Malaiselvan

2

Dans un premier temps, je suggère de rétablir vos paramètres pour les paramètres cron par défaut de Magento:

Paramètres par défaut de Magento Cron

Il y a un problème avec vos paramètres actuels: votre emploi du temps est généré toutes les 15 minutes mais uniquement planifié à l'avance pendant 5 minutes, ce qui laisse un intervalle de 10 minutes.


Merci. Même après avoir réinitialisé les paramètres par défaut, cela ne fonctionne pas. Lors de sa première exécution, il a créé tous les travaux de la table cron_schedule avec l'heure planifiée. Les emplois ne sont jamais sélectionnés et restent dans la table comme en attente pour toujours. Une chose que j'ai remarquée après la configuration $isShellDisabled = true;et lorsque je lance Cron.php via le navigateur, les tâches sont sélectionnées, mais pas via CronTab.
Malaiselvan

Ce problème n'est pas encore résolu. Y aura-t-il un problème avec mon hébergeur. Je vois le script déclenché à intervalles réguliers mais seuls les travaux ne sont pas sélectionnés. Cela posera-t-il également un problème puisque j'ai migré de la version 1.8?
Malaiselvan

Votre cronjob a-t-il assez de mémoire? Essayez les journaux d'erreurs pour voir s'il y a quelque chose qui pourrait vous aider.
Kristof au Fooman

ce problème n'est pas encore résolu ... Tous les jours je me casse la tête. Journaux d'erreurs? où puis-je les voir?
Malaiselvan

@Malaiselvan pour les journaux d'erreurs, veuillez vérifier avec votre administrateur système ou votre hébergeur car ils doivent connaître l'emplacement et comment accéder au journal d'erreurs du serveur. En outre, il peut être utile d'exécuter manuellement le travail cron à partir de la ligne de commande - essayez les deux php -f cron.phpet ./cron.shvoyez s'ils produisent quelque chose à approfondir.
Kristof à Fooman

1

Même problème pour moi.

Erreur "Trop tard ..." trouvée.

Après le nettoyage de la cron_scheduletable, cron.sh a cessé de fonctionner (plus de planification).

Fonctionne uniquement après avoir tué tous les anciens processus Cron.


Dans mon cas, lorsque Cron s'exécute pour la première fois, il a réussi à créer les tâches dans le tableau. Mais il n'exécute jamais la tâche. :-(
Malaiselvan

1

J'ai eu le même problème. Mon problème était spécifique au fuseau horaire: les colonnes created_atet scheduled_atdans le cron_scheduletableau devraient être UTC + 0, mes entrées étaient UTC + 2.

Pour vérifier cela , vous pouvez simplement les dates de created_atet scheduled_athier et d' attendre jusqu'à ce que le prochain programme de Cron.

J'espère que cela aide quelqu'un!


1

Sur Bluehost, dans cron.sh change

 PHP_BIN=`which php`

à

 PHP_BIN="php54s"

Par défaut, dans l'hébergement partagé, il exécute PHP 5.2.

J'ai aussi dû changer cron.php, en remplaçant les deux $isShellDisabledlignes par $isShellDisabled = true;

Pour se débarrasser des avertissements PHP, j'ai également ajouté ces lignes avant

$_SERVER['SCRIPT_NAME'] = 

if (empty($_SERVER['SCRIPT_FILENAME'])) $_SERVER['SCRIPT_FILENAME'] = '~/public_html/cron.php';
if (empty($_SERVER['SCRIPT_NAME'])) $_SERVER['SCRIPT_NAME'] = '/cron.php';
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.