You are not logged in.
Bonjour,
Voici la configuration de mon serveur : Red Hat AS5, ocs v1.02 et glpi v0.71.5
J'ai rencontré un soucis avec le plugin Import en masse OCS #1.2.1.
Je lance l'import toutes les minutes sur mon serveur.
Ce matin à 9H07 min, le plugin a arrêté de fonctionner (sans intervention aucune).
En regardant les processus qui tournaient :
apache ... 09:07 0:00 /bin/sh le chemin vers le fichier ocsfullsinc.sh
apache ... 09:07 0:01 php -q -d -f ocsng_fullsync.php --ocs_server_id=1 --thread_nbr=2 --thread_id=2
Je tu ces deux processus.
L'import à l'air de repartir... Je vois mes deux processus dans l'interface en train d'importer les postes.
Et là à 16% pour un et 30% pour l'autre processus, j'ai le même soucis.
14H45 : Heure où j'ai tué les deux précédents process.
apache 14:45 0:00 /bin/sh /.../scripts/ocsng_fullsync.sh --thread_nbr=2 --ser...
apache 14:45 0:29 php -q -d -f ocsng_fullsync.php --ocs_server_id=1 --thread_nbr=2 --thread_id=1 --process_id=
apache 14:45 0:05 php -q -d -f ocsng_fullsync.php --ocs_server_id=1 --thread_nbr=2 --thread_id=2 --process_id=
Le processus reste, mais plus rien ne se passe sur GLPI. Depuis 30 minutes, aucune évolution.
Avez vous déjà rencontré ce problème ?
Y'a t'il un moyen de limité le temps d'activité du processus pour le désactiver automatiquement sans avoir à tuer des processus ?
Merci de votre aide,
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Il y a un petit bug sur la 1.2.1, essai la 1.2.2
Mais c'est juste un problème de numérotation des processus...
Lance le en ligne de commande (en interactif) avec l'option --nolog pour voir ce qui se passe en temps réel (des points doivent apparaitre pour chaque machine traitée, et ça peut être assez long s'il y en a beaucoup).
+
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
Entre chaque test ci dessous, je kill les processus (pour reprendre un import normal).
J'ai essayé de lier tous les postes sous OCS qui peuvent l'être automatiquement.
Résultat : idem !
Tous ceux qui ne peuvent pas être liés ET qui ont une proposition car il y a un autre poste du même nom je les aient importés.
Résultat : idem !
J'ai vérifié ma base OCS à la recherche d'un poste qui peut poser soucis : suppression des postes sans aucune information (ex : pas de nom, ni de domaine ni le reste et je les aient supprimé.
Résultat : idem !
J'importe les postes restants à importer dans GLPI.
Le processus arrive à son terme et l'import reprend automatiquement.
Est ce un problème lié à l'import d'une machine ??
Merci pour le conseil remi, mais je n'ai pas vu ton message à temps.
Je vérifierais ta solution si le problème réapparait.
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Ce matin même soucis, je test avec le nolog. --> Ca passe. Je le met dans le cron avec export en fichier texte pour voir...
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
> Je le met dans le cron avec export en fichier texte
Inutile, sans l'option ça va directement dans un fichier texte....
Voir si le fait de l'avoir fait tourner en interactif (utilisateur root je suppose) n'aurait pas créé des fichiers (cache, lock) empéchant le fonctionnement normal pour l'utilisateur apache
+
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
Bizarrement, depuis que j'ai lancé la tache cron avec nolog, il n'y a pas d'erreurs.
Je laisse tourner le script pour le moment. Je surveille ..
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Ça recommence :
apache 10:24 0:00 /bin/sh -c /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh --thread_nbr=2 --
apache 10:24 0:00 /bin/sh /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh --thread_nbr=2 --ser
apache 10:24 0:00 php -q -d -f ocsng_fullsync.php --ocs_server_id=1 --thread_nbr=2 --thread_id=1 --process_id=
Il est 11H et pas d'import depuis 10H24.
Il n'y a rien dans les fichiers ...glpi/files/_lock/...
Pour les fichiers de cache, il y a beaucoups de répertoire et je ne vois pas ce qu'il faut que je regarde.
Là je seiche...
Voici le fichier de log :
Fri Apr 24 10:22:01 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
Clean old Not Imported machine list (0)
Manage delete items in OCS server #1: "OCSNG"
Thread #1 : starting (1/2)
thread #1 : import computers from server: 'OCSNG'
thread #1 : 2 computer(s)
..Thread #2 : starting (2/2)
thread #2 : import computers from server: 'OCSNG'
thread #2 : 1 computer(s)
.^MThread #1 : done ..
^MThread #2 : done ..
cleaning up.
Fri Apr 24 10:22:03 CEST 2009 ended
Fri Apr 24 10:23:02 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
Clean old Not Imported machine list (0)
Manage delete items in OCS server #1: "OCSNG"
Thread #1 : starting (1/2)
thread #1 : import computers from server: 'OCSNG'
thread #1 : 4 computer(s)
....^MThread #1 : done ..
Thread #2 : starting (2/2)
thread #2 : import computers from server: 'OCSNG'
thread #2 : 2 computer(s)
..^MThread #2 : done ..
cleaning up.
Fri Apr 24 10:23:04 CEST 2009 ended
Fri Apr 24 10:24:01 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
Clean old Not Imported machine list (0)
Manage delete items in OCS server #1: "OCSNGt"
Thread #1 : starting (1/2)
thread #1 : import computers from server: 'OCSNG'
thread #1 : 4 computer(s)
....Thread #2 : starting (2/2)
thread #2 : import computers from server: 'OCSNG'
thread #2 : 1 computer(s)
.^MThread #2 : done ..
Je précise que les processus lié à l'import de 10H24 tournent toujours.
il n'y a pas de cleaning up à la fin du log ?
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
On dirait que le Thread #1 a fini de traiter ses 4 ordinateurs avant le lancement du second...
Vu qu'il y a quand même peu de machines à chaque passage, essaie de n'utiliser qu'un seul thread.
> Pour les fichiers de cache, il y a beaucoups de répertoire et je ne vois pas ce qu'il faut que je regarde.
Regarde le propriétaire (ce doit être apache et rien d'autre)
+
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
On dirait que le Thread #1 a fini de traiter ses 4 ordinateurs avant le lancement du second...
Vu qu'il y a quand même peu de machines à chaque passage, essaie de n'utiliser qu'un seul thread.
Ça a très bien fonctionné pendant 6 mois. Je vais modifié ça...
> Pour les fichiers de cache, il y a beaucoups de répertoire et je ne vois pas ce qu'il faut que je regarde.
Regarde le propriétaire (ce doit être apache et rien d'autre)
+
J'ai dans glpi/fils/_cache :
18 apache apache cache_0
18 apache apache cache_1
18 apache apache cache_2
18 apache apache cache_3
18 apache apache cache_4
18 apache apache cache_5
18 apache apache cache_6
18 apache apache cache_7
18 apache apache cache_8
18 apache apache cache_9
18 apache apache cache_a
18 apache apache cache_b
18 apache apache cache_c
18 apache apache cache_d
18 apache apache cache_e
18 apache apache cache_f
et pour exemple dans cache f :
cache_f0 cache_f2 cache_f4 cache_f6 cache_f8 cache_fa cache_fc cache_fe
cache_f1 cache_f3 cache_f5 cache_f7 cache_f9 cache_fb cache_fd cache_ff
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Même avec 1 seul processus d'import, j'ai le même soucis.
Synchro de 198 poste puis plus rien... Processus toujours actifs...Mais qui ne font plus rien.
Le passage en version 1.2.2 du plugin peut il corriger ce problème ???
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
> Le passage en version 1.2.2 du plugin peut il corriger ce problème ???
La correction est vraiment mineure, mais oui il ne faut pas rester en 1.2.1
+
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
Je n'ai pas changé de version pour le moment.
J'ai modifié le ocsfullsync.php pour remplacer le . de chaque pc par son id ocs.
J'ai tué le processus qui restait sur le serveur et tout est reparti ????
Comme hier, j'attends que le phénomène se reproduit.
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Le problème s'est reproduit dés le 27-04.
Même résolution : kill du processus et l'inventaire se refait automatiquement (j'ai dût tuer plusieurs processus avant que celui ci commence à se faire automatiquement).
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Le problème ne vient pas d'un poste en particulier. Il se produit avec 1 ou 2 thread.
C'est le processus du ocsng_fulsync.PHP qui se plante.
Dans le fichier de log, japrès un kill du processus j'ai : var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh: line 152: 18240 Killed sh -c "$cmd"
Je regarde ligne 152 : il s'agit d'un wait à la fin du script.
Y a t'il un mode debug du plugin ou de GLPI ou on pourrait tracer tout ce qui se passe au niveau de l'import ocs ?
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Je viens d'installer la version 1.2.2 : Elle s'installe.
Par contre, même si je lance le script toutes les minutes, rien n'est importé ..
Dans le fichier de log de ocsfullsync.log j'ai : (même avec l'option --nolog)
Mon May 4 16:06:02 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
cleaning up.
Mon May 4 16:06:03 CEST 2009 ended
Mon May 4 16:07:01 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
cleaning up.
Mon May 4 16:07:03 CEST 2009 ended
Mon May 4 16:08:01 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
cleaning up.
Mon May 4 16:08:02 CEST 2009 ended
Mon May 4 16:09:02 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
cleaning up.
Mon May 4 16:09:03 CEST 2009 ended
Mon May 4 16:10:01 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
cleaning up.
Mon May 4 16:10:03 CEST 2009 ended
Mon May 4 16:11:01 CEST 2009 /var/www/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
cleaning up.
Mon May 4 16:11:03 CEST 2009 ended
Je repasse en 1.2.1 et là tout est réimporté ..
Puisque mon probleme revient, y a t'il un moyen de limiter le temps d'execution du script.
Je vois dans le fichier /glpi/plugin/mass_ocs_import_ocsngfullsync.ph :
ini_set("memory_limit","-1");^M
ini_set("max_execution_time", "0");^M
Comment l'utiliser ??
Last edited by fabibus (2009-05-04 16:37:48)
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline
Bon, après mise en place d'indicateur dans le fichier ocsng_fullsync.sh et glpi/inc/ocsng.function.php, le problème vient d'un fichier de lock qui me bloque l'import sur certaines entitée.
Les locks supprimés, l'import se relance de lui même.
Tu avais raison remi, c'était bien un fichier de lock. Je comprend mieux leur utilité....
Plateforme en exploitation : GLPI 10.0.3 + GLPiinventory 10.0.3sur Fedora 36
PHP 8.1.11 ,Apache/2.4.54, mysql 8
Offline