You are not logged in.
Bonjour,
J'ai fait le tour des topic qui en parlait mais j'ai pas la réponse à mon problème ..
J'ai migré de serveur UBUNTU SERVER ver UBUNTU SERVER / GLPI 0.84.70 vers 0.84.70 avec toute ma base ...
Le collecteur marchait très bien en CLI avec un cron sur l'ancien mais impossible à le faire sur le nouveau serveur.
Le mailgate reste en "cours d'execution" bloqué.
Lorsque je l'annule et lance la commande suivante, ça fonctionne en partie.
php5 /var/www/glpi/front/cron.php --force debug mailgate
Le mailgate est lancé mais reste bloqué "en cours d'execution"
Quand je l'execute à la main dans les action automatique, cela fonctionne.
Pas d'erreur significative dans syslog, dans cron.log.
Cron.log :
Externe #1 : Rien à lancer
2014-09-03 17:47:01
Externe #1 : Rien à lancer
2014-09-03 17:48:01
Externe #1 : Rien à lancer
2014-09-03 17:49:02
Externe #1 : Rien à lancer
2014-09-03 17:50:01
Externe #1 : Rien à lancer
2014-09-03 17:50:10
Interne #1 : Démarrage planningrecall
ANNULATON MANUELLE DE L'EXECUTION AUTOMATIQUE
2014-09-03 17:51:01
Externe #1 : Démarrage mailgate
BLOCAGE A NOUVEAU "en cours d'execution"
J'ai l'impression que c'est la fonction maigate qui échoue mais je ne sais pas ou.
J'ai vérifié tous les droits ...
Merci d'avance pour votre aide.
Offline
Dans les actions automatiques, cliquer sur la croix à côté d'en cours d'exécution et celle Dernière exécution.
Vous avez dû migrer votre serveur alors qu'une action était en cours.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
Merci pour votre réponse.
J'ai déjà fait cette manip plusieurs fois et elle a comme effet de libérer le mailgate.
Le cron relance ensuite le mailgate selon la fréquence définie et on se retrouve à nouveau bloqué "en cours d'execution".
Mes log cron sans syslog :
Sep 4 13:20:01 SRV-GLPI CRON[22749]: (www-data) CMD (/usr/bin/php5 /var/www/glpi/front/cron.php)
Sep 4 13:20:01 SRV-GLPI CRON[22750]: (www-data) CMD (/usr/bin/php5 /usr/share/glpi/front/cron.php)
En fait, le glpi avait été installé à l'origine dans le /usr/share et a été ensuite déplacé dans le /var/www/
J'ai rajouter dans le crontab de www-data la ligne suivante mais je n'arrive pas a supprimé celle qui pointe vers le /usr/share.
*/1 * * * * /usr/bin/php5 /var/www/glpi/front/cron.php
Je ne retrouve cet autre cron nulpar ..
Merci d'avance,
Offline
Bonjour,
Bon, j'ai réinstaller tout le serveur proprement en suivant les procédure et j'ai toujours exactement le même résultat sans erreur dans les log a part : "rien a lancer" ...
Help please ....! :S
Offline
Bonjour,
Bon j'ai un peu avancé sur mon problème :
Après avoir réinstallé tout mon serveur, j'ai fais des tests dans tous les sens pour comprendre le problème et je me suis aperçu d'un truc : Si je désactive le collecteur mail, le mailgate fonctionne très bien en mode CLI et s'execute comme prévu dans mon cron tous les minutes (*/1 * * * *) sauf qu'il n'a pas de collecteur a verifier ...
Dès que j'active mon collecteur de mail, l'action automatique se retrouve "en cours d'exécution"... dès la première fréquence du cron ... Etonnant
J'ai vérifié le paramétrage de mon collecteur plusieurs fois et ... identique ..
Pourtant, si j'execute ce même collecteur manuellement (récuprer les mails), il fonctionne ..! Donc, pas de problème réseau non plus ... Je n'y comprend rien ..
Comment fonctionne le mailgate via le pseudo cron de GLPI ? quelqu'un a une idée ?
Y a t-il des fichiers particuliers utilisé ou je pourrai avoir des problèmes de droits ?
Pour info, ma migration de serveur se fait depuis une VPS OVH vers une VM hébergé chez moi.
Aidez moi SVP .....
Merci d'avance
Offline
up .. personne ?
Offline
..?? Je suis toujours bloqué ...
Est-ce qu'une bonne âme pourrai m'aider ?
Merci d'avance :S
Offline
OVH... il y a plein de topic à ce sujet dans le forum.
Avez-vous des errors dans les logs de GLPI? (/files/_logs/)
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Oui, j'ai vu et étant donné les problèmes chez OVH, notement d'envoi d'email, j'ai décidé de le rapatrié sur mes serveurs..
Le problème est le comportement de mon serveur local alors que le serveur OVH fonctionne très bien (pour la partie mailgate)...
J'ai déjà cherché sur les topics mais aucun ne correspond à mon problème.
Non, aucune erreur ! C'est bien ça mon problème .. sans erreur, il est très compliqué de comprendre le pb ...
Merci
Offline
Up pleaze ..
Offline
Bonjour,
Je re fait un petit up du sujet car je suis toujours bloqué au même endroit ..
Si quelqu'un a une idée, je suis vraiment intéressé ..
Merci d'avance pour votre aide
Offline
Le problème est résolu.
J'ai basculé en mode GLPI et est éditer un script qui execute une requette http sur le cron.php toutes les minutes (à l'aide de cron).
Offline
Un petit complément.
J'avais le même soucis (changement de serveur Ubuntu), mais un autre topic m'a aidé à résoudre le problème.
Pour que le mode CLI fonctionne il m'a fallu ajouter la ligne suivante au fichier /etc/php5/cli/php.ini :
extension=imap.so
et bien sûr avoir dans le crontab root ou apache :
*/1 * * * * /usr/bin/php /var/www/html/glpi/front/cron.php
Merci pour le topic suivant http://www.glpi-project.org/forum/viewt … p?id=34976
Cordialement
Offline