OVH Community, votre nouvel espace communautaire.

taches planifiés ne s'executent plus


elmanu
14/04/2016, 02h26
Citation Envoyé par SI_Christophe
En fait, les variables $_GET, $_POST ne fonctionnent pas sous ce nom là en PHP CLI, c'est vrai.

Il faut utiliser cette technique:
Appeller votre page PHP via un .sh qui lui sera lancé par CRON.

Dans le .sh, vous pouvez alors utiliser:

--post-data pour ENVOYER en POST des informations sur la page distante PHP receveuse via PHP CLI:
EXEMPLE: wget --post-data 'backupAction=zone_client' -O /dev/null 'http://www.site_a_contacter.fr/page.php'

--get-data pour ENVOYER en GET des informations sur la page distante PHP receveuse via PHP CLI:
EXEMPLE: wget --get-data 'backupAction=zone_client' -O /dev/null 'http://www.site_a_contacter.fr/page.php'
.....
...wow, ça me sauverait la vie, mais quand j'essaie j'ai une erreur : --get-data n'est pas une option valide (et n'existe pas dans la doc)

Je dois lancer en cron un truc du genre cron.php?arg1=val1&arg2=val2&arg3=val3 et je m'arrache les cheveux dessus !!

Une idée, quelqu'un ?

Merci d'avance !

Jikoo
13/10/2014, 17h02
Phil54,

De mon côté, voici, ce que j'ai remarqué:
Citation Envoyé par Jikoo
Personnellement, c'est en constatant des bugs lors de la "gestion" des Crons que j'ai vu des différences notables entre le nouveau manager et l'ancien. Ce que tu fais dans l'un n'est pas forcément reproduit à l'identique dans l'autre.

phil54
13/10/2014, 16h48
A vrai dire, je pense qu'il y'a dans mon cas un bug sur le nouveau manager (comme je l'ai expliqué plus haut).
J'étais donc allé sur l'ancien manager (heureusement qu'il est encore là), j'avais supprimé la tâche puis recréée, là sans aucun problème.

Puis le lendemain, je me suis aperçu que la tâche avait été lancée avec succès 3 fois !! Je pense donc que les tâches que j'avais essayé de programmer dans le nouveau manager ont été transférées dans l'ancien car celui-ci en comportait désormais 3 au lieu d'une...

Mon avis (mais c'est seulement une hypothèse) est que les tâches qui étaient lancées depuis le 29 septembre provenaient du nouveau manager (celui où il m'est toujours impossible de supprimer ni de créer une tâche), et que suite à mon ticket incident, c'est l'ancien qui s'occupe de nouveau du lancement depuis hier...

Ca me parait le plus logique... mais je peux me tromper...

Jikoo
13/10/2014, 16h01
Citation Envoyé par phil54
En ce qui me concerne, le problème semble résolu depuis hier puisque le script s'exécute de nouveau correctement sans modification de celui-ci. Pourvu que ça dure
Veinard !
Apparemment, ce n'est pas le cas pour tout le monde !
http://forum.ovh.com/showthread.php?...l=1#post621053 (Posté le même jour !^^)

phil54
13/10/2014, 07h42
En ce qui me concerne, le problème semble résolu depuis hier puisque le script s'exécute de nouveau correctement sans modification de celui-ci. Pourvu que ça dure

Jikoo
11/10/2014, 23h42
Merci SI_Christophe! La méthode de Abazada me semble plus complexe. Donc pour l'instant, j'utilise ta méthode!
Avant, je faisais une requête asyncrone en JS vers un fichier PHP avec mes arguments POST pour récupérer du Json basique. J'avais bien sûr mis un cache pour éviter les requêtes inutiles. Ca marchait très bien. En tous cas, en Cron, c'est beaucoup mieux, plus sécurisé, plus propre. Merci les gars pour votre aide.

SI_Christophe
11/10/2014, 20h36
Citation Envoyé par Abazada
Disons que c'est une solution, mais pas celle que j'utilise

Il faut bien comprendre qu'avec ta méthode tu fais exécuter ton Php à travers Apache, avec toutes les contraintes sur Php qui lui sont associées.
En particulier les limites sur le temps d'exécution et la mémoire utilisable sont en général beaucoup plus faibles, ce qui peut-être un sérieux soucis pour un script cron de maintenance qui peut être "un peu" long et gourmand...

Perso j'utilise aussi un script bash pour lancer ces Php, mais je passe mes variables en ligne
Code:
# $PHP54 path/file.php a=123 b=toto
et dans mon programme je reconstruis $_GET à partir de $argv si besoin, via l'appel d'un fonction updateGetFromArgv()
qui est à coder en s'inspirant (copiant?) par exemple de http://php.net/manual/fr/reserved.va...rgv.php#113614
Entièrement d'accord, de la façon dont moi j'en avais besoin, (il fallait que le script soit lancé d'un user 'php', j'étais donc obligé de procéder comme j'ai fais.
Mais ta technique, méconnue, est très viable aussi.

Ravi de voir que mon petit tutoriel sur la façon de le faire en a inspiré d'autres pour poster leurs méthodes


Citation Envoyé par Jikoo
Christophe, c'est génial! Merci beaucoup. Je me suis toujours demandé comment on pouvait faire, surtout pour le $_POST[].
Operation très facile à réaliser, grâce à toi.
Mais de rien
Demande d'ami accepté, au plaisir

Jikoo
11/10/2014, 19h29
[2014-10-10 04:57:03] command /homez.68/........ must be executable
[2014-10-10 04:57:03] -- 2014-10-10 06:57:03.803239 exitcode: 255
J'ai eu le même souci. Je l'ai résolu avec le CHMOD 705 sur le fichier appelé par le crontab.

Pour le reste, tu n'as pas de chance. Je n'ai pas rencontré de bug dans le nouveau manager pour ajouter/éditer/supprimer une tâche planifiée.

phil54
11/10/2014, 16h36
Merci pour vos réponses.

Effectivement, avec les identifiants du manager, ça fonctionne beaucoup mieux

A priori, rien de spécial dans les logs :
[2014-10-10 04:57:03] command /homez.68/........ must be executable
[2014-10-10 04:57:03] -- 2014-10-10 06:57:03.803239 exitcode: 255
Je vais voir avec le support pour qu'ils me suppriment la tâche dans le nouveau manager et pour que je puisse en recréer une nouvelle, j'ai l'impression que le problème vient de là.

Je viens de refaire l'essai de supprimer la tâche existante : Impossible, j'obtiens le message :
Une erreur est survenue lors de la demande de suppression de la tâche Cron. (Object of type 'l1::hosting::Crontab' does not exist)
d'en créer une nouvelle : Impossible (bien que le message m'indique que la tâche sera disponible dans moins de 2 mn...
et si je modifie l'existante, ça me donne le message d'erreur :
Une erreur est survenue lors de l'édition de la tâche 96414. (Object of type 'l1::hosting::Crontab' does not exist (id: '96414'))
Bref, je vais refaire un nouveau ticket...

romainovh
11/10/2014, 11h59
Hello

Désormais il semble qu'aucun accès n'est créé par défaut pour consulter les logs. Ce fut le cas pour moi.

Tu dois créer un compte sur le manager (https://www.ovh.com/managerv3/), Hébergement->Statistiques->Création.

Abazada
11/10/2014, 10h24
Citation Envoyé par phil54
Merci Jikoo, oui, concernant le nouveau manager, la valeur PHP est effectivement à "autre" et impossible de la modifier puisqu'aucun changement n'est pris en compte !!
Visiblement dans le même cas que moi. La gestion des crons est juste *totalement inutilisable* sur le V6 (avec des crons qui manquent et des champs qui s'efface aléatoirement!) pour mon hébergement type PRO. Je n'utilise donc pour les CRON que le V3 qui est ok.

Citation Envoyé par phil54
Ensuite, pour aller consulter les logs sur https://logs.ovh.net/, j'avoue que je ne parviens pas à m'y connecter, j'ai utilisé mes codes FTP mais visiblement, il faut mettre autre chose
Pour les logs, même identifiant que pour l'accès au manager. Donc xxxx-OVH / passwd

phil54
11/10/2014, 09h13
Merci Jikoo, oui, concernant le nouveau manager, la valeur PHP est effectivement à "autre" et impossible de la modifier puisqu'aucun changement n'est pris en compte !!

Ensuite, pour aller consulter les logs sur https://logs.ovh.net/, j'avoue que je ne parviens pas à m'y connecter, j'ai utilisé mes codes FTP mais visiblement, il faut mettre autre chose

Cela dit, pour le mail de logs que j'avais reçu il y'a quelques jours, la valeur exitcode: était : 255

Je vais faire une batterie de tests pendant ce week-end...

Jikoo
11/10/2014, 08h57
phil54,

Pour tester, fais marcher ton script TOUTES les heures et regarde plutôt tes logs CRON sur https://logs.ovh.net/
Normalement, l'erreur exitcode va t'informer du problème.

Perso, jutilise jamais les mails. En plus, il y a quelques jours, ils marchaient mal. J'en parlais le 30/09/2014:
http://forum.ovh.com/showthread.php?...l=1#post619419

Citation Envoyé par phil54
OVH m'a conseillé de supprimer puis de recréer la tâche dans le manager, mais dans le joli manager tout neuf, impossible de supprimer la tâche existante et la nouvelle tâche que je crée n'y apparait pas
Donc je reviens à l'ancien manager, je supprime l'ancienne tâche, ça fonctionne puis je recrée la nouvelle, ça refonctionne.
Là je me dis c'est top, je retourne sur le nouveau manager pour vérifier et là, seule l'ancienne tâche apparait toujours...!
Visiblement, tu as un souci avec le nouveau manager. Il bugge chez toi. (Chez moi, pas de souci de ce niveau là)
C'est peut être ça le souci. Assure toi que dans le manager, la bonne version de PHP est bien renseignée sur ta tâche planifiée. Pendant un temps, la valeur se remettait sur Autre.


Citation Envoyé par Jikoo
Ma petite contribution pour faire fonctionner les tâches planifiées sur des fichiers PHP.
http://forum.ovh.com/showthread.php?...l=1#post620507

phil54
11/10/2014, 08h25
Bonjour à tous,

Comme bien d'autres, je suis confronté à ce problème de Cron depuis le 29 septembre et n'ai pas encore réussi à le résoudre !!

J'ai changé mon include en chemin absolu, pas de changement, j'ai appliqué la méthode de Jikoo, sans succès,...

J'ai reçu une réponse OVH le 10 octobre suite à un ticket incident, qui me conseille de regarder les logs envoyés par mail, sauf que je n'en ai reçu qu'un depuis le 29 septembre qui ne donne aucune indication sinon que le lancement à eu lieu.
OVH m'a conseillé de supprimer puis de recréer la tâche dans le manager, mais dans le joli manager tout neuf, impossible de supprimer la tâche existante et la nouvelle tâche que je crée n'y apparait pas
Donc je reviens à l'ancien manager, je supprime l'ancienne tâche, ça fonctionne puis je recrée la nouvelle, ça refonctionne.
Là je me dis c'est top, je retourne sur le nouveau manager pour vérifier et là, seule l'ancienne tâche apparait toujours...

Bref, je ne sais plus quoi penser... Je vais attendre demain... on ne sait jamais...

Edit à 9h37 : Je viens de recevoir une réponse de OVH qui m'indique que le problème doit venir de mon script... Ce script qui tournait sans problème depuis plus de 6 mois... Et aucune mention du changement opéré le 29 septembre... c'est fou !

Jikoo
10/10/2014, 17h44
Waoooow Abazada ! ^^
Merci pour ta solution intéressante. J'en prends note.

Abazada
10/10/2014, 17h29
Citation Envoyé par SI_Christophe
En fait, les variables $_GET, $_POST ne fonctionnent pas sous ce nom là en PHP CLI, c'est vrai.
Il faut utiliser cette technique:
...
Disons que c'est une solution, mais pas celle que j'utilise

Il faut bien comprendre qu'avec ta méthode tu fais exécuter ton Php à travers Apache, avec toutes les contraintes sur Php qui lui sont associées.
En particulier les limites sur le temps d'exécution et la mémoire utilisable sont en général beaucoup plus faibles, ce qui peut-être un sérieux soucis pour un script cron de maintenance qui peut être "un peu" long et gourmand...

Perso j'utilise aussi un script bash pour lancer ces Php, mais je passe mes variables en ligne
Code:
# $PHP54 path/file.php a=123 b=toto
et dans mon programme je reconstruis $_GET à partir de $argv si besoin, via l'appel d'un fonction updateGetFromArgv()
qui est à coder en s'inspirant (copiant?) par exemple de http://php.net/manual/fr/reserved.va...rgv.php#113614

Jikoo
10/10/2014, 17h27
Christophe, c'est génial! Merci beaucoup. Je me suis toujours demandé comment on pouvait faire, surtout pour le $_POST[].
Operation très facile à réaliser, grâce à toi.

SI_Christophe
10/10/2014, 17h17
Citation Envoyé par Jikoo
Excellent tuto. Merci pour l'aide.
Mais de rien, j'utilise ma technique sur un site en production qui effectue des backups SQL de tables au choix, d'où les paramètres 'POST/GET' et ce via un .sh lancé via CRON.
Sinon, j'ai corrigé une petite erreur de frappe, j'ai écris deux fois --post-data, j'ai fixé mon erreur !

Jikoo
10/10/2014, 15h51
Merci à vous tous.

Citation Envoyé par Abazada
Le point 3) est inutile
A partir du moment que tu indiques dans le manager que ton cron est du Php5.4 (par exemple)
il ne sert à rien de mettre "#!/usr/local/bin/php.ORIG.5_4" en 1ère ligne
Visiblement, nous n'avons pas la même config. Je suis sur un vieux Mutu Perso. La version de PHP est bien renseignée sur le Cron, dans le manager.
Si je ne mets pas cette ligne, le Cron renvoit une erreur dans mes logs:
Exec format error
exitcode: 255

J'en parle ici: http://forum.ovh.com/showthread.php?...l=1#post620683


Citation Envoyé par Abazada
De même pour le point 4). Inutile. Tous mes sources cron Php sont en 400 et ça marche très bien
Visiblement, nous n'avons pas la même config. Je suis sur un vieux Mutu Perso.
Si je ne mets pas le CHMOD 705, le Cron renvoit une erreur dans mes logs:
monscript.php must be executable
exitcode: 255



Citation Envoyé par SI_Christophe
En fait, les variables $_GET, $_POST ne fonctionnent pas sous ce nom là en PHP CLI, c'est vrai.

Il faut utiliser cette technique:
Appeller votre page PHP via un .sh qui lui sera lancé par CRON.
Excellent tuto. Merci pour l'aide.

SI_Christophe
10/10/2014, 14h32
Citation Envoyé par Jikoo
Je vous rappelle aussi que les variables globales comme $_SERVER, $_GET... ne fonctionnent pas en "mode Cron" (PHP CLI).
En fait, les variables $_GET, $_POST ne fonctionnent pas sous ce nom là en PHP CLI, c'est vrai.

Il faut utiliser cette technique:
Appeller votre page PHP via un .sh qui lui sera lancé par CRON.

Dans le .sh, vous pouvez alors utiliser:

--post-data pour ENVOYER en POST des informations sur la page distante PHP receveuse via PHP CLI:
EXEMPLE: wget --post-data 'backupAction=zone_client' -O /dev/null 'http://www.site_a_contacter.fr/page.php'

--get-data pour ENVOYER en GET des informations sur la page distante PHP receveuse via PHP CLI:
EXEMPLE: wget --get-data 'backupAction=zone_client' -O /dev/null 'http://www.site_a_contacter.fr/page.php'

Pour ajouter plus d'une informations, séparez les par des: &
(et Même si il s'agit de la PREMIERE information SECONDAIRE), pas par des '?' et si vous devez écrire (sans interpréter '&', pensez à le remplacer par un truc genre: [AMPERSAND] et à en effectuer le remplacement par '&' depuis la page PHP.

Exemples valide:
wget --post-data 'backupAction=zone_client&typeAction=action1&debug Flag=no' -O /dev/null 'http://www.site_a_contacter.fr/page.php'

Exemples invalides:
wget --post-data 'backupAction=zone_client?typeAction=action1&debug Flag=no' -O /dev/null 'http://www.site_a_contacter.fr/page.php'
wget --post-data 'backupAction=zone_client&typeAction=action1&debug &Flag=no' -O /dev/null 'http://www.site_a_contacter.fr/page.php'

--> Dans la dernière déclaration, il y aura alors; debug valorisé à vide et Flag à la valeur 'no'..

Et pour la page PHP ?

A ce moment, là, vous pourrez vous servir de $_GET[] ou $_POST[]

Abazada
10/10/2014, 10h04
Sympa ton tuto Jikoo
Quelques Remarques:

Le point 3) est inutile
A partir du moment que tu indiques dans le manager que ton cron est du Php5.4 (par exemple)
il ne sert à rien de mettre "#!/usr/local/bin/php.ORIG.5_4" en 1ère ligne

C'est bien plus pratique car tu peux utiliser ce source aussi bien en cron, qu'en shell ou en web

OVH lance en fait les crons via une commande:
# /usr/local/php5.4/bin/php /homez.XXX/user/path/file.php

Ca permet de profiter du dernier Php 5.4 installé par OVH: Actuellement 5.4.30

De même pour le point 4). Inutile. Tous mes sources cron Php sont en 400 et ça marche très bien

Iwazaru
09/10/2014, 08h59
Super clair, ça aide beaucoup, merci !

Jikoo
08/10/2014, 23h15
Chers développeurs,

Bon, comme mes Crons (tâches planifiées) fonctionnent tous depuis plusieurs jours, je viens vous donner un coup de main. Pour mon cas, j'ai moi même résolu le problème. Je n'ai jamais contacté le support OVH.


RAPPEL QUI NOUS CONCERNE TOUS
Problèmes connus suite à la migration OVH Cron
http://travaux.ovh.net/?do=details&id=11645


CONSTAT
Le Crontab (planificateur des tâches) fonctionne bien. Cependant, l'environnement d'exécution a changé. Il y a un problème d'arborescence des fichiers.


MES POSTS IMPORTANTS
30/09/2014: Détection du problème de chemin relatif/absolu des fichiers PHP
http://forum.ovh.com/showthread.php?...l=1#post619419

01/10/2014: Petit test d'un Cron réalisé par mes soins:
http://forum.ovh.com/showthread.php?...l=1#post619540


CONTEXTE PERSONNEL
Scripts PHP 5.4 exécutés sur Mutu Perso (60GP) cluster 010.
Cette fois-ci, la configuration des tâches planifiées est réalisée uniquement sur le NOUVEAU Manager.

J'utilise plusieurs classes PHP et créés mes propres fichier-logs, ce qui fait que pour moi l'arborescence des fichiers est très importante.


TUTO EN 4 POINTS

1) Bien configurer chaque Cron (tâche planifiée) dans le manager.


2) Assurer vous de mettre des chemins absolus dans vos includes et appel de fichier PHP.

Exemple de chemins relatifs:
(Ca, ça marchait avant... mais maintenant, ça ne marche plus si vous devez remonter dans l'arborescence)
Code PHP:
require '../dossier1/include1.php';
require 
'../dossier2/include2.php';
require 
'../include3.php'
Désormais, il faut utiliser les chemins absolus:
Code PHP:
$path dirname(dirname(__FILE__));
define('ROOT',dirname($path));

require 
ROOT.'/dossier1/include1.php';
require 
ROOT.'/dossier2/include2.php';
require 
ROOT.'/include3.php'
C'est un exemple. Evidemment, cela est à adapter pour votre cas.
Comme j'utilise plusieurs classes PHP et me balade dans l'arborescence montante et descendante du site, j'ai créé une constante 'ROOT' pour plus de facilité.
Je vous conseille aussi de vous créer une fonction qui génére tout ça automatiquement car si votre /homez.xxx/ change de nom, vous serez plus tranquille. De plus, j'utilise WAMP Server sur Windows, comme ça la fonction est compatible sur Linux Apache (en ligne) et Windows (chez moi). A vous de la créer! ^^
Je vous rappelle aussi que les variables globales comme $_SERVER, $_GET... ne fonctionnent pas en "mode Cron" (PHP CLI).


3) Tous mes scripts PHP utilisent la version 5.4. Par conséquent, dans le fichier PHP, mettre à la 1ère ligne:
#!/usr/local/bin/php.ORIG.5_4

Exemple:
Code:
#!/usr/local/bin/php.ORIG.5_4

4) Mettre un CHMOD 705 (exécution) à tous vos fichiers PHP appelés par le Crontab. Ce n'est pas la peine de changer le CHMOD des autres dossiers et fichiers.


Pour finir, surveiller vos logs CRON dans: logs.ovh.net/mondomaine.tld/
Le résultat de l'exécution de vos Crons doit avoir: exitcode: 0


TOPICS LIES AU MEME PROBLEME

CONCLUSION
En espérant avoir apporté un peu d'aide. J'ai quand même passé un peu de temps pour cette explication!
Je ne suis pas de la team OVH.
Merci de votre attention.

manud
07/10/2014, 18h34
Les scripts indiqués dans le manager en PHP 5.2 n'ont pas le problème du changement de racine qui se résoud en changeant les liens relatifs en absolus.
Le problème apparaît à partir de PHP 5.3.

@Team OVH : avez-vous une explication sur cette différence ? Est-ce normal et définitif ? Merci d'avance.

orix
07/10/2014, 11h44
Je me sens moins seul. Ces threads traitent tous du même problème:
http://forum.ovh.com/showthread.php?101140
http://forum.ovh.com/showthread.php?101095
http://forum.ovh.com/showthread.php?101031
http://forum.ovh.com/showthread.php?101040

manud
05/10/2014, 16h10
Depuis hier je modifie aussi tous les chemins de mes includes... Super week-end !

Henrie
05/10/2014, 15h49
merci beaucoup en modifiant les chemins cela refonctionne mais OVH aurait pu nous prévenir quand même !
Il doit y avoir pas mal de monde a qui ca pose des problemes.

manud
04/10/2014, 10h49
Citation Envoyé par Jikoo
C'est un problème d'arborecence. Il faut utiliser les chemins absolus.
Ca ne fonctionne plus avec les chemins relatifs.
http://forum.ovh.com/showthread.php?...l=1#post619957
Je confirme, c'est bien un problème de chemin absolu dans les include.
ça fonctionnait depuis des années et plus du jour au lendemain.

C'est bien à OVH de rétablir la situation.

romainovh
04/10/2014, 10h10
Utiliser les chemins absolus, c'est peut-être une solution, mais elle doit être temporaire. Ce n'est pas envisageable à long terme.

Ca fait plus d'une semaine que nos crons ne fonctionnent plus :
- Soit on a tous fait du mauvais code avec nos chemins relatifs et on avait de la chance que ça fonctionnait.......... Faudrait qu'on soit informés.
- Soit l'équipe d'ovh résout le problème pour que ça fonctionne correctement (merci et courage ;-)

Bonne journée

Jikoo
03/10/2014, 16h38
C'est un problème d'arborecence. Il faut utiliser les chemins absolus.
Ca ne fonctionne plus avec les chemins relatifs.
http://forum.ovh.com/showthread.php?...l=1#post619957

bossboss
02/10/2014, 23h36
Il semblerait que ça refonctionne un peu à suivre.....

Henrie
02/10/2014, 17h13
Je constate que ne suis pas le seul dans ce cas ( ca me rassure et rassure pas a la fois )
j'ai pris le serveur il y a peu et ce que je constate c'est qu'a ce prix c'est quand meme inadmissible qu un tel probleme reste sans solution depuis plus d'une semaine ( pour ma part ) que le service technique m'envoie sur les roses. De ce fait mon site est completement bloqué a cause de ce probleme ( vu que cest un jeu les actualisations auto en sont le coeur ) pour moi c'est un scandale !

bossboss
02/10/2014, 01h29
Citation Envoyé par Jikoo
Moi aussi, j'ai toujours exitcode 255 sur mes scripts.
J'ai fais un petit test sur une nouvelle tâche CRON. Et le résultat est exitcode 0 ^^
http://forum.ovh.com/showthread.php?...l=1#post619540
Idem que vous. Les taches planifiées ne s'executent qu'aléatoirement, 1X par jour au lieu de toutes les heures !.....

j'ai du remédier rapidement au problème en les lançant via serveur distant. !

Jikoo
01/10/2014, 20h46
Moi aussi, j'ai toujours exitcode 255 sur mes scripts.
J'ai fais un petit test sur une nouvelle tâche CRON. Et le résultat est exitcode 0 ^^
http://forum.ovh.com/showthread.php?...l=1#post619540

Henrie
01/10/2014, 14h29
Bonjour , avez-vous eu un résultat ?
a la base le chemin etait "/www/chemin_du_script.php"
je l'ai changé en " /home/xxx/www/chemin_du_script.php".
Mais cela n'a pas lair dy changer quelque choses ^^ .Mais cetait a tenter .
Je confirme que les envoies des logs se passent un peu en random .
Je viens de remarquer qu il me donne un code erreur 255 sur une des taches ( sur 12 );
J'ai ouvert un ticket mais a ce jour rien n'est reglé ! ca fait une semaine que ca tourne en rond

Jikoo
30/09/2014, 23h44
Cher Henrie, moi aussi, en ce moment, j'ai des soucis avec les tâches planifiées.
J'ai déjà exposé mon problème. Ca peut peut-être t'aider: http://forum.ovh.com/showthread.php?...l=1#post619419
Bon courage!

Henrie
30/09/2014, 23h15
Bonjour,
je suis en mutu perf 4
depuis le 23/09/14 13h les taches planifiées ne s exécutent plus , pourtant quand je les lancent depuis l url pas de probleme tout fonctionnent parfaitement .
les logs me renvois un codeexit :0 .
J ai essayé plusieurs manip ( ex chmod de 604 a 704 ,700 )
mais rien n'y fait .
Auriez-vous des idées pour me sortitr de cette panade ?
merci d'avance ^^