You are not logged in.
Bonjour à tous,
Je suis confronté au problème suivant : la fonction mailgate reste bloquée lors de l'exécution automatique.
- mon collecteur est un mail infomaniak sur mon domaine, et il est parfaitement fonctionnel en manuel (collecteur -> récupérer maintenant => ok). Je l'utilise en /pop/notls
- Le mailgate est lancé en CLI sur mon serveur. (les logs du CRON n'indiquent aucune erreur, et listent bien l'execution du mailgate) - [128Mo pour le CLI]
- Paramétrage de l'action automatique : 5min / CLI / 0-24h / 30jours / 10 messages.
- Je n'ai aucune erreur reliée dans les _log
L'action automatique reste bloquée sur "en cours d’exécution". Si je l'annule et la lance manuellement (prochaine exécution => exécuter) j'ai un fonctionnement normal...
Merci d'avance pour vos retours, idées ou suggestions.
(GLPI 0.80.61 + fusion inventory 0.80+1.1
WAMP)
-----
Résolu avec la proposition suivante par Flo.flo78
Après bidouillage ça fonctionne ..! Au niveau du collecteur il faut le mettre sur glpi et mettre le code joint dans un fichier .php que tu lances en tâche planifiée.
<?php
set_time_limit(120);
file_get_contents('http://127.0.0.1/glpi/front/cron.php');
?>
Last edited by Madsupcom (2012-09-18 09:06:12)
Offline
1/ activer les traces dans les journaux
2/ vérifier le contenu des journaux au moement de l'éxécution
Pour aller plus loin
3/ appliquer le correctif :
https://forge.indepnet.net/projects/glp … 18451/diff
4/ lancer l'exécution en ligne de commande (après avoir effacer la date de dernière exécution) avec les options
php /chemin/vers/glpi/front/cron.php --debug --force mailgate
et voir si un message s'affiche.
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Rebonjour,
Merci pour votre réponse rapide !
Alors, journaux activés = aucune trace lors d'un lancement automatique, trace =ok lors d'un lancement manuel...
J'ai réalisé les étapes 3 et 4 :
Première exécution j'ai le message ci dessous :
C:\wamp\bin\php\php5.3.5>php.exe /wamp/apps/glpi/front/cron.php --debug --force
mailgate
PHP Warning: error_log(../files/_log/php-errors.log): failed to open stream: Pe
rmission denied in C:\wamp\apps\glpi\inc\common.function.php on line 241
PHP Stack trace:
PHP 1. {main}() C:\wamp\apps\glpi\front\cron.php:0
PHP 2. include() C:\wamp\apps\glpi\front\cron.php:41
PHP 3. Plugin::load() C:\wamp\apps\glpi\inc\includes.php:175
PHP 4. plugin_init_datainjection() C:\wamp\apps\glpi\inc\plugin.class.php:117
PHP 5. logDebug() C:\wamp\apps\glpi\plugins\datainjection\setup.php:50
PHP 6. logInFile() C:\wamp\apps\glpi\inc\common.function.php:267
PHP 7. error_log() C:\wamp\apps\glpi\inc\common.function.php:241
PHP 8. userErrorHandlerNormal() C:\wamp\apps\glpi\inc\common.function.php:0
PHP 9. logInFile() C:\wamp\apps\glpi\inc\common.function.php:325
PHP 10. error_log() C:\wamp\apps\glpi\inc\common.function.php:241
ERROR : ../files/_lock not writable
run script as 'apache' user
=> j'ai désinstallé le plugin datainjection qui semblait avoir un impact, et j'ai relancé cette fois en mode admin (pour la partie not writable, par élimination)
Résultat : plus aucune erreur dans la ligne de commande
Pourtant, mailgate reste bloqué avec toujours ce message : En cours d'exécution...
Cordialement.
Offline
Bonjour,
Après divers tests et recherches, je reste toujours bloqué...
'Mailgate En cours d'exécution' depuis vendredi, la surveillance des tâches me remonte ce blocage
Auriez vous une piste ou des tests complémentaires à me proposer ?
Merci d'avance.
Bien cordialement.
Offline
Vérifiez qu'apache soit bien le propriétaire en récursif du dossier glpi/files.
En effet, en regardant vos messages d'erreur, GLPI ne peut pas écrire dans glpis/files/_lock ni _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
Rebonjour,
Merci pour votre nouveau retour. Comme indiqué plus haut, j'ai repassé le CRON en tache auto lancée par l'admin serveur. Je viens de revoir l'ensemble des droits pour la partie wamp/apps/glpi, et tout est ok.
Tant Wamp que le Cron ont accès à cette arborescence en "controle total".
Mail gate relancé, même erreur. Le lancement manuel fonctionne toujours pour sa part o-O'
Bien cordialement.
Offline
Normalement, dans mes souvenirs de windows, il faut que la tâche automatique soit lancée par l'utilisateur l'ayant créée. Le problème vient peut être de là.
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
Je viens de remodifier la tâche automatique, et là encore aucun changement.
Actuellement : le dossier /glpi appartient - est créé par l'user lançant la tâche auto avec 'contrôle total' sur ce dossier et ces sous éléments.
Même constat.
Cordialement.
Offline
Bonjour,
Je suis toujours bloqué :
- mailgate bloque -En cours d'exécution-
- lancement du dit mailgate par un cron en mode CLI (128Mb) par l'utilisateur propriétaire et disposant du contrôle total de toute l'arbo GLPI.
- aucune trace d'erreur dans les logs, le lancement de mailgate est présent, c'est tout...
Merci d'avance pour toute piste que vous pourriez me proposer de creuser.
Cordialement.
Offline
Bonjour,
Toujours bloqué par mon problème de mailgate, adieu veaux, vaches, collecteur mail ?
Cordialement.
Offline
Si ça pète, c'est qu'il y a une erreur
Je vous ai fournit un correctif permettant de forcer le mode "debug" pour capter cette erreur.
Donc assurez vous de
1/ effacer la date de dernière execution pour que la tache ne soit plus "en cours"
2/ lancer avec les options données
3/ vérifier les log
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Hello
Merci pour ce nouveau retour...
Alors, j'ai remis en place le correctif et relancé x fois le cron en cli / console / debug y compris en administrateur pour éviter tout problème de droits.
J'arrive désormais à ce message d'erreur que je n'avais pas précédemment, mais qui semble indiquer un problème dans la partie modifiée par le correctif...
Notice: GLPI autoload : file ../inc/session.class.php not founded trying to load class 'Session' in C:\wamp\apps\glpi\inc\includes.php on line 98
Call Stack:
0.0009 338016
1. {main}() C:\wamp\apps\glpi\front\cron.php:0
0.0022 397992
2. include('C:\wamp\apps\glpi\inc\includes.php') C:\wamp\apps\glpi\front\cron.php:41
0.0444 4022072
3. include_once('C:\wamp\apps\glpi\config\config.php') C:\wamp\apps\glpi\inc\includes.php:121
0.0702 4834600
4. __autoload() C:\wamp\apps\glpi\inc\includes.php:0
0.0705 4835016
5. trigger_error() C:\wamp\apps\glpi\inc\includes.php:98
Fatal error: Class 'Session' not found in C:\wamp\apps\glpi\config\config.php on line 138
Call Stack:
0.0009 338016
1. {main}() C:\wamp\apps\glpi\front\cron.php:0
0.0022 397992
2. include('C:\wamp\apps\glpi\inc\includes.php') C:\wamp\apps\glpi\front\cron.php:41
0.0444 4022072
3. include_once('C:\wamp\apps\glpi\config\config.php') C:\wamp\apps\glpi\inc\includes.php:121
Ps : le correctif indiqué fait que le mailgate ne se lance plus du tout en mode débug, donc encore moins de logs pour moi :'(
Last edited by Madsupcom (2012-05-21 12:07:33)
Offline
Là, je vois pas
Faut voir avec un Windowsien.
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Merci pour ton temps et tes efforts
Offline
Ah si merde, j'avais pas vu la version (0.80.61)
Donc, sur le correctif, remplacer Session::DEBUG_MODE par juste DEBUG_MODE
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Merci !
On en revient à la situation précédente : cela lance mon mailgate, mais il reste toujours en cours d'execution, et ZERO log ou retour sur la commande.
/o\
Offline
Bonjour,
Je suis toujours bloqué... Une suggestion ?
Merci d'avance.
Cordialement.
Offline
Bonjour,
A titre d'info, ça m'arrive aussi, depuis plusieurs jours, surtout depuis que l'on fait un usage intense du ticketing et du collecteur. mailgate bloqué "en cours d'exécution", et le collecteur marche manuellement.
Conf : 0.83.1 + Comportements.
Je viens d'activer toutes les traces. Si j'ai quelque chose de significatif, je poste.
Offline
Merci !
Je suis preneur de toute éventuelle trace dont tu disposerais, chez moi c'est RAS...
Cordialement.
Offline
Bonjour,
Je continue à chercher, sans résultat pour le moment...
Bon we !
Cordialement.
Offline
Bonjour,
Je me permets de remonter un peu ce topic...
Mon CRON aboutit toujours à un mailgate bloqué... Le mailgate déclenché manuellement continue à fonctionner...
Cordialement.
Offline
Salut,
Seulement le collecteur ne fonctionne pas en CLI ou aucune tache ne fonctionne ?
As tu configurer l’authentification automatique sans mod_ntlm ?
Offline
Hello,
Merci pour ton retour.
Alors :
- Toutes mes autres tâches en mode CLI fonctionnement bien. Seul le mailgate se lance, bloque (sans message ou log) et reste lancé/bloqué
- Pas de trace du module mod_ntlm dans mon apache, pas de module du même nom dans GLPI...
Mes options de connexion au niveau mail sont en NO-TLS si c'est ce que tu me demandes ?
Une piste ?
Merci.
Cordialement.
Offline
bonjour,
je suis toujours bloqué.
Une piste ?
Merci.
Cordialement.
Offline
bonjour, pour info je rencontre le même problème (GLPI 0.83.3/PHP 5.2.4-2/Ubuntu 8.04.1)
La récupération fonctionne bien en manuel, mais reste sur "Prochaine exécution : En cours d'exécution" quand lancée automatiquement.
Cela fonctionnait avant des maj glpi 0.72 -> 0.80
Offline