You are not logged in.
Bonjour,
j'ai le message suivant " Le cron GLPI ne fonctionne pas,"
avez vous une idée ?
Merci
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
Bonjour,
version de GLPI ?
serveur widows ou linux ?
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
Bonjour,
La version de GLPI 9.1.1
Linux debian 8.7 (jessie)
merci
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
personne ?
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
même avec un réinstallation cela ne marche pas
Last edited by bzh (2017-01-19 00:19:17)
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
dans quelles conditions apparait le message ?
quels plugins sont installés (et versions) ?
quel est le contenu de la crontab ?
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
Cela se produit quand je vais sur le plugin fusionInventory
j'ai fait le test de supprimer le plugin pour le réinstaller mais même résultat
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
Bah t'as le cron GLPI qui tourne? cf la doc
Offline
Je ne comprend pas pourquoi sur une config propre cela ne produit pas les même résultat.
et j'ai regardé un peu la doc mais c'est un nébuleux,
http://glpi-project.org/DOC/FR/glpi/con … skcli.html
La présence du fichier GLPI/files/_cron/all.lock verrouille toutes les actions.
La présence d'un fichier GLPI/files/ verrouille l'action nom.
pas de fichier présent (all.lock / _cron/nom.lock)
et cela ne me parle pas (je ne connais pas le PHP (avec un peu humour (j'aimerais bien, mais je peu point) )
alors avec ça comme info : je nage
Appel avec surcharge de la configuration
Ex: PHP GLPI/front/cron.php 5
a+
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
effectivement cron me retourne une erreur
cron can't lock /var/run/crond.pid otherpid may be 407
resource temporarily unavaibable
mais cela ne me dit pas grand chose
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
dans la version 9.1 (qui fonction au niveau de fusioninventory
// Ensure current directory when run from crontab
chdir(dirname($_SERVER["SCRIPT_FILENAME"]));
dans la version 9.1.1
// Ensure current directory when run from crontab
chdir(_DIR_);
normal cette différence ?
Last edited by bzh (2017-01-23 09:04:32)
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
> cron can't lock /var/run/crond.pid otherpid may be 407
Donc problème système, pas GLPI.
> normal cet différence ?
oui, "cette" différence est normale
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
Rémi,
Ok c'est système, mais la je sèche, et j'ai fait a un moment une modif dans crontab et en fait j'ai du ajouter un pb au lieu de résoudre et je ne sais même plus ou j'ai modifier le crontab et je tour en rond .
Si tu peut m'aider ?
merci
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
j'ai avancé, j'ai supprimé la ligne que j'ai ajouté pour tester !
mais j'ai une nouvelle erreur
cron can't /var/run/crond Pid otherpid mais be 2505
mais ce qui m'étonne c'est que j'ai eu deux remonter de machine
Last edited by bzh (2017-04-12 15:53:25)
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
toujours pas de solution j'ai fait la mise a jour de glpi 9.1.2
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
dans le dossier Glpi\files\_cron (je n'est rien)
Normale ?
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
Ce n'est pas un problème GLPI mais un problème système au niveau du lancement de vos cron
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
avec la commande /etc/init.d/cron stop
donne le même résultat !
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
j'ai fait un autre test avec
For Linux, add in crontab:
* * * * * /usr/bin/php5 /var/www/glpi/front/cron.php &>/dev/null
source : http://fusioninventory.org/documentation/fi4g/cron.html
même résultat
je tourne en rond !
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
peut etre modifier la timezone de php cli
Offline
j'ai placé cela mais même resultat
date.timezone = 'Europe/Paris';
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
GLPI / FusionInventory
Le cron GLPI ne fonctionne pas, voir documentation
Vérifier en 1er lieu si " taskscheduler" est lancé
Configuration=> Actions automatiques.
Virtual Box \ Ubuntu 20.4 \ GLPI 9.5.3
Offline
attention parfois glpi peut être dans www/html/
le cron devient alors
* * * * * /usr/bin/php5 /var/www/html/glpi/front/cron.php &>/dev/null
(si vous êtes bien en php5)
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
déjà enlever le >/dev/null pour que les erreurs de cron soient tracées
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,
Server Windows 2012 R2 (A jour)
Server WEB IIS Microsoft (A jour)
GLPI (dernière version)
Fusioninventory (dernière version)
Tout fonctionnait bien, le message " Le cron GLPI ne fonctionne pas, voir documentation " avait disparu en suivant la procédure de la documentation présent sur leur site web
http://fusioninventory.org/documentation/fi4g/cron.html.
Au bout d'une semaine le message est revenu, J'ai vérifié et la tache est toujours présente/actif et fonctionnelle.
Auriez-vous une idée? svp.
Merci beaucoup.
Offline