You are not logged in.
Bonjour,
J'ai passé la journée à éplucher le forum afin de trouver une solution mais rien, je m'en remet à vos conseils ..
Serveur GLPI: Win 2008 R2
XAMPP 3.2.2
Mon problème: J'ai migrer mon serveur GLPI 9.0 vers 9.2, aucun message d'erreur dans les logs.
Le site m'a l'air de fonctionné correctement à part un service relativement très important, les Actions automatiques.
Aucune actions ne fonctionnent, que ce soit en CLI ou en GLPI.
J'ai également un script ( C:\xampp\php\php.exe -f c:/xampp/htdocs/glpi/front/cron.php) que je lance avec le planificateur de tache windows, mais cela n'a aucun effet.
Quand j'execute une actions, quel quel soit, je n'ai aucun retour. Les statistiques sont à 0 et les logs sont vides.
Pour info, j'ai activé la journalisation complete du site ainsi que les traceurs mais les logs sont toujours vide.
Le répertoire _cron est vide également.
J'ai également désactiver tous les plugins.
Edit: Je n'ai pas de plugin Fusion, donc pas d'action taskscheduler.
D'avance merci,
Last edited by titan (2017-12-28 17:06:39)
Offline
Bonsoir,
Je rencontre le même souci.
J'ai migré le 03/11 de 9.1.6 à 9.2 après avoir fait le tour en base de test pour laquelle je désactive les notifications ... une erreur ; car depuis cet upgrade mon CRON ne fonctionne plus.
Dommage que dans les Actions offertes de la vue Actions automatiques on ne puisse pas les exécuter "dés que possible" au lieu de procéder une à une.
Cordialement,
Last edited by typtop21 (2017-11-07 20:03:06)
Les erreurs sont les portes de la découverte.
Chacun a en soi les prémices de la grandeur mais peu va savoir se mettre à la barre et choisir le bon cap.
Ils seront encore moins à prendre le temps pour montrer la route aux autres ....
W2012r2 | Xampp | Glpi 9.2.3
Offline
salut tout le monde,
Il semblerais que je ne soit pas le seul a avoir le même problème.
j'ai une VM 2008 R2 avec XAMPP et une autre VM pour test avec le même système. Sur les deux j'ai un problème identique: ne récupère pas les tickets automatiquement.
Le CRON est OK (je l'ai même re-crée pour être sur) mais il n’exécute pas les taches auto. Par contre la récupération manuelle des mails fonctionne.
Tout ça est suite a l'updrade de glpi 9.1 vers 9.2
Voici un printscreen du mode "debug" en ligne de commande.
auriez-vous des idées?
Offline
attention : en 9.2 queued mail est devenu queued notification.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Merci LaDenrée d'avoir répondu aussi vite. Mais je n'ai pas de queued notifications dans la liste des actions automatiques.
Peut-être c'est a cause de ça ?!
(desolé le printscreen est un peut grand)
Offline
normalement il y a ça :
planningrecall Rappel du planning Envoyer les rappels pour le planning Programmée 2017-11-08 14:57
queuednotification File d'attente des notifications Envoyer les courriels en attente Programmée 2017-11-08 14:57
queuednotificationclean File d'attente des notifications Vider la file d'attente des notifications Programmée 2017-11-04 03:05
reservation Élément réservable Alertes sur les réservations Désactivée 2015-06-16 00:03
c'est sûr qu'il y a un problème sur cette action automatique et que ça explique que les mais ne partent plus tout seuls.
je n'ai malheureusement pas de fix à proposer, mais il y a plusieurs sujets ouverts sur le forum, il y a déjà peut être une solution.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Pour ma part :
C:\xampp\php>php C:\xampp\htdocs\glpi\front\cron.php --debug
PHP Warning: Module 'openssl' already loaded in Unknown on line 0
Warning: Module 'openssl' already loaded in Unknown on line 0
Externe #1 : D├®marrage queuednotification
Externe #2 : D├®marrage queuednotificationclean
C:\xampp\php>
Les erreurs sont les portes de la découverte.
Chacun a en soi les prémices de la grandeur mais peu va savoir se mettre à la barre et choisir le bon cap.
Ils seront encore moins à prendre le temps pour montrer la route aux autres ....
W2012r2 | Xampp | Glpi 9.2.3
Offline
Tu as raison!
Je viens d'installer une version "propre" de glpi 9.2 sans faire des "upgrade" et j'ai la meme chose que toi
Peut-être c'est un problème /bug?
Oui effectivement il a pas mal de topics ouverts a propos de ce problème, mais jusqu’à présent je ne vois pas comment résoudre
Offline
je propose cet update : ( après avoir vérifie que les ID sont les mêmes sur votre base et avoir fait un dump)
UPDATE `glpi_crontasks` SET `itemtype` = 'QueuedNotification', `name` = 'queuednotification' WHERE `glpi_crontasks`.`id` = 29;
UPDATE `glpi_crontasks` SET `itemtype` = 'QueuedNotification', `name` = 'queuednotificationclean' WHERE `glpi_crontasks`.`id` = 30;
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Je teste ta solution @LaDenrée
Voici le résultat...
(je ne suis pas bon en SQL)
Offline
Je teste ta solution @LaDenrée
Voici le résultat...
https://img4.hostingpics.net/pics/33091 … stance.png
(je ne suis pas bon en SQL)
Pas mieux mais avec des ID différents 27 et 28
Les erreurs sont les portes de la découverte.
Chacun a en soi les prémices de la grandeur mais peu va savoir se mettre à la barre et choisir le bon cap.
Ils seront encore moins à prendre le temps pour montrer la route aux autres ....
W2012r2 | Xampp | Glpi 9.2.3
Offline
@alexi :
avez vous selectionné la bonne base de donnée ?
que vous retourne
select * from 'glpi_crontask'
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
@LaDenrée Bonjour,
Désolé ça fait une semaine que je dois te répondre
Oui je sélectionne le bonne BDD et non, aucun changement.
Je remarqué aussi que des qu'on ajoute un suivi a un ticket, la personne qui a ouvert un ticket ne reçoit pas la notification par email
Dans Configuration>Notifications>Configuration des suivis par courriels>Verifier le certificat est "NON". Le test a l'administrateur est OK (avec et sans le certificat)
N’hésitez pas a poster vos propositions !
Offline
J'ai trouvé ........................
Je ne sait pour quelle raison, mais la migration me viander les actions automatiques à chaque fois.
Je lancer la migration avec le serveur en mode maintenance et sur mon dernier test je l'ai désactivé.
La migration c'est correctement déroulé et les actions automatiques fonctionnent, un vrai régal ..
Pour moi tout fonctionne correctement, vous pouvez cloturer le ticket.
Offline