You are not logged in.
Salut à tous.
J'ai la version 9.4.2 de GLPI.
J'ai activé les notifications par mail et j'ai configuré mes données, tout fonctionne bien de ce côté là.
Par contre je rencontre un bug ou j'utilise mal les réglages pour les notifications par mail.
Pour l'action automatique "queuednotification" , j'ai choisi comme mode d'exécution CLI. Ensuite j'ai créé un fichier .bat en inscrivant dedans "C:\wamp64\bin\php\php5.6.40\php.exe" "C:\wamp64\www\glpi\front\cron.php" et pour finir j'ai créé une tâche planifié qui s'exécute toute les 5 minutes.
L'appel s'effectue bien car dans le fichier cron.log je vois bien que queuednotification est lancé.
Mais seulement, je ne vois pas les mails arrivés.
Si je clique sur sur exécuter directement pour queuednotification, le/les mails arrivent bien.
Du coup, j'ai regardé un peu le code, et je vois que la différence est au niveau du mode 1 ou -1 , bref avant d'envisager une étude plus approfondit du code, j'aimerai vos avis.
Merci d'avance !
Offline
Et pourquoi ne pas appeler le cron directement dans la tache planifiée plutôt que de passer par un .bat ? Même si en théorie cela ne change rien.
programme appelé : C:\wamp64\bin\php\php5.6.40\php.exe
argument : C:\wamp64\www\glpi\front\cron.php
Le mode 1 ou -1 doit être la différence entre le mode CLI et le mode GLPI
Question bête mais le service php actif est bien le 5.6.40 ?
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
Oui le service php est le bon, j'ai même tester directement via la commande C:\WINDOWS\system32>php C:\wamp64\www\glpi\front\cron.php
avec l'invite de commande en mode administrateur.
J'ai bien ça dans les logs du cron
2019-08-19 11:41:00 [@MTP-10-022]
Externe #1 : Démarrage queuednotification
Mais rien y fait !
Edit: Et j'ai fait la mise à jour vers 9.4.3, et c'est pareil.
Last edited by Isia (2019-08-19 13:43:39)
Offline
Et avec les autres actions automatiques de GLPI, ça donne quoi ?
Vérifie aussi l’exécution du taskscheduler (de fusion) ; en principe sans rapports, sauf que je l'ai déjà vu planté et me bloquer les autres traitements !
Parfois aussi, faire un arrêt de la tache et une relance manuelle, débloque la tâche.
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
Je vois que tu as pu éditer ton propre message ... j'ai pas cette option chez moi !
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
Fusion ? tu parles du plugin ? je ne m'en sert pas, il n'est pas installé. A moins que tu parles d'autre chose
Quand je la passe en manuel, ça fonctionne ! Mais ça n'appelle pas le même fichier, ça appelle crontask.form.php.
Offline
Re,
Bon ce matin ça fonctionne.
J'ai constaté un écart sur les heures entre l'heure réelle et l'heure sur les logs. Du coup j'ai configuré le fichier C:\wamp64\bin\php\php5.6.40\phpForApache.ini et le fichier C:\wamp64\bin\php\php5.6.40\php.ini en mettant :
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone ="Europe/Paris"
Dans les 2.
Dans un premier temps, je l'avais fait que sur php.ini mais apparemment il faut appliquer la modification sur les 2.
J'ai relancé Wamp, exécuté les tâches en attente. Et j'ai lancé mon planificateur de tâche.
Offline