• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Agent 2.3.16 et les taches
#1
Bonjour

Est ce que l'agent 2.3.16 corrige la gestion des taches

DECOUVERTE RESEAU
[Mon Mar 23 09:02:18 2015][debug] scanning block 10.10.112.10-10.10.112.30
[Mon Mar 23 09:02:18 2015][debug2] [http client] sending message:

L'agent reste toujours en cours alors que la plage d'execution est terminée


[Mon Mar 23 09:02:57 2015][debug] [thread 2] scanning 10.10.112.30:
[Mon Mar 23 09:02:58 2015][debug] [thread 2] - scanning 10.10.112.30 with netbios: no result
[Mon Mar 23 09:02:59 2015][debug] [thread 2] - scanning 10.10.112.30 with SNMP, credentials 1: no result
[Mon Mar 23 09:02:59 2015][debug] [thread 2] termination
[Mon Mar 23 09:03:01 2015][debug] [http server] request / from client 127.0.0.1
[Mon Mar 23 09:03:01 2015][debug] [http server] response status 200
[Mon Mar 23 09:03:02 2015][debug] [http server] request /site.css from client 127.0.0.1
[Mon Mar 23 09:03:02 2015][debug] [http server] response status 200
[Mon Mar 23 09:03:03 2015][debug] [http server] request /logo.png from client 127.0.0.1
[Mon Mar 23 09:03:03 2015][debug] [http server] response status 200
[Mon Mar 23 09:03:05 2015][debug] [http server] request / from client 127.0.0.1
[Mon Mar 23 09:03:05 2015][debug] [http server] response status 200

[Mon Mar 23 09:14:21 2015][debug] [http server] request /site.css from client 127.0.0.1
[Mon Mar 23 09:14:21 2015][debug] [http server] response status 200
[Mon Mar 23 09:14:22 2015][debug] [http server] request /logo.png from client 127.0.0.1
[Mon Mar 23 09:14:22 2015][debug] [http server] response status 200

Je ne comprends pas aussi pourquoi j'ne n'ai pas une mise a jour sur l'imprimante 10.10.112.10 mais Import Réfusé
alors que la OKI est a l'adresse 10.10.112.4 et j'ai bien "Mise a jour..."

2015-03-23 09:02:26 En cours d'exécution [Détail] Mise à jour de l'objet Imprimante OKI_MB471
2015-03-23 09:02:26 En cours d'exécution 1 périphériques trouvés
2015-03-23 09:02:24 En cours d'exécution Import refusé [serial]:ALJ0543AC, [mac]:00:d0:fe:d1:b6:c5, [ip]:10.10.112.10, [entities_id]:5, [itemtype]Tonguerinter
2015-03-23 09:02:24 En cours d'exécution 1 périphériques trouvés
Merci

GLPI 0.90.5/ Plugins Fusion : 090+1.4 / Agent : 2.3.18 < Serveur Centos 64 Bits>
  Reply
#2
J'ai decidé d'arreter le service et le redemarrer
J'ai donc eu l'erreur suivante à 12:47 suite au redémarrage ...
Ce qui veut bien dire qu'il était toujours en cours

2015-03-23 12:47:30 Erreur L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique

2015-03-23 09:02:26 En cours d'exécution [Détail] Mise à jour de l'objet Imprimante OKI_MB471
2015-03-23 09:02:26 En cours d'exécution 1 périphériques trouvés
Merci

GLPI 0.90.5/ Plugins Fusion : 090+1.4 / Agent : 2.3.18 < Serveur Centos 64 Bits>
  Reply
#3
Bonjour
J'ai aussi le même problème.
Agent 2.3.16 windows (j'ai essayé debian, c'est pareil)
Serveur 0.85.2 Synology
Les tâches de découverte ou d'inventaire réseau débutent bien, font leur boulot, mais ne s'arrêtent jamais : elles ont toujours en cours.
Après un redémarrage de l'agent, le job passe en erreur.

Une idée d'où ça vient ?
  Reply
#4
Bonjour,
le même problème pour moi , avec agent (2.3.16) windows , j'ai toujours
2015-03-26 08:58:15 Erreur L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique
2015-03-25 10:57:47 Démarré 2 threads
2015-03-25 10:57:01 Préparé
mais avec agent (2.3.16) linux , tous fonctionnent bien , préparé >en cour > succès , j'ai bien voir le vert
  Reply
#5
hhusihai Wrote:Bonjour,
le même problème pour moi , avec agent (2.3.16) windows , j'ai toujours
2015-03-26 08:58:15 Erreur L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique
2015-03-25 10:57:47 Démarré 2 threads
2015-03-25 10:57:01 Préparé
mais avec agent (2.3.16) linux , tous fonctionnent bien , préparé >en cour > succès , j'ai bien voir le vert

Bonjour.
Avez-vous lancé plusieurs la tache ?
Chez moi, la première fois, ça a bien fonctionné, mais pas la deuxième.
  Reply
#6
OlivierB Wrote:
hhusihai Wrote:Bonjour,
le même problème pour moi , avec agent (2.3.16) windows , j'ai toujours
2015-03-26 08:58:15 Erreur L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique
2015-03-25 10:57:47 Démarré 2 threads
2015-03-25 10:57:01 Préparé
mais avec agent (2.3.16) linux , tous fonctionnent bien , préparé >en cour > succès , j'ai bien voir le vert

Bonjour.
Avez-vous lancé plusieurs la tache ?
Chez moi, la première fois, ça a bien fonctionné, mais pas la deuxième.


oui, plusieurs avec agent linux , tout va bien, mais toujours pas avec agent windows
  Reply
#7
Bon, je progresse lentement.
J'ai mon agent Linux qui a quand même un problème (ou le serveur glpi) : quand je créée une tache d'inventaire SNMP avec un job dedans qui cible un switch, j'ai bien l'inventaire SNMP qui remonte.
Dès que je mais une 2ième cible dans le job, ou que je créée un second job dans cette même tache, ou que je créée une 2nde tâche d'inventaire snmp, la première se déroule correctement, et la seconde est toujours en cours, et passe en erreur lors de l'inventaire suivant.
Il y a surement un quelque chose que je fais mal (j'étais habitué à l'ancienne version, avec définition des modèles SNMP)
Pour info, voici le log de l'agent :
Code:
[Wed Apr  1 08:24:58 2015][info] sending prolog request to server server0
[Wed Apr  1 08:24:58 2015][debug] forking process 16567 to handle task ESX
[Wed Apr  1 08:24:58 2015][info] running task ESX
[Wed Apr  1 08:24:58 2015][info] ESX support disabled server side.
[Wed Apr  1 08:25:04 2015][debug] forking process 16568 to handle task Inventory
[Wed Apr  1 08:25:04 2015][info] running task Inventory
[Wed Apr  1 08:25:04 2015][debug] Running FusionInventory::Agent::Task::Inventory::AccessLog
...
[Wed Apr  1 08:25:05 2015][debug] Section HARDWARE has changed since last inventory
[Wed Apr  1 08:25:10 2015][debug] forking process 16628 to handle task WakeOnLan
[Wed Apr  1 08:25:10 2015][debug] WakeOnLan task execution not requested
[Wed Apr  1 08:25:16 2015][debug] forking process 16629 to handle task NetDiscovery
[Wed Apr  1 08:25:16 2015][debug] NetDiscovery task execution not requested
[Wed Apr  1 08:25:22 2015][debug] forking process 16630 to handle task Deploy
[Wed Apr  1 08:25:22 2015][info] running task Deploy
[Wed Apr  1 08:25:28 2015][debug] forking process 16631 to handle task NetInventory
[Wed Apr  1 08:25:28 2015][info] running task NetInventory
[Wed Apr  1 08:25:28 2015][debug] [http client] Using Compress::Zlib for compression
[Wed Apr  1 08:25:28 2015][debug] creating 1 worker threads
[Wed Apr  1 08:25:28 2015][debug] [thread 1] creation
[Wed Apr  1 08:25:28 2015][debug] [thread 1] scanning 1
[Wed Apr  1 08:25:28 2015][debug] full match for sysobjectID .1.3.6.1.4.1.11.2.3.7.11.64 in database
[Wed Apr  1 08:25:35 2015][debug] [thread 1] termination
[Wed Apr  1 08:25:37 2015][debug] cleaning 1 worker threads
  Reply
#8
Bonjour

Mon agent reste bloque après la découverte de la plage ip
Ce n'est qu'aujourd'hui en relancant force fusioninventory que la ligne du 7 Avril est apparu dans le log

[Mon Mar 30 11:04:48 2015][debug] [thread 2] scanning 172.19.3.254:
[Mon Mar 30 11:04:48 2015][debug] [thread 2] - scanning 172.19.3.254 with netbios: no result
[Mon Mar 30 11:04:50 2015][debug] [thread 2] - scanning 172.19.3.254 with SNMP, credentials 1: no result
[Mon Mar 30 11:04:50 2015][debug] [thread 2] termination
[Tue Apr 7 10:47:40 2015][debug] [http server] request /status from client 10.10.7.10
[Tue Apr 7 10:47:40 2015][debug] [http server] response status 200
[Tue Apr 7 10:49:10 2015][debug] [http server] request / from client 127.0.0.1
[Tue Apr 7 10:49:10 2015][debug] [http server] response status 200
Merci

GLPI 0.90.5/ Plugins Fusion : 090+1.4 / Agent : 2.3.18 < Serveur Centos 64 Bits>
  Reply
#9
J'ai testé avec une nouvelle installation à 0 sous Centos 7 64 bits avec GLPI 0.85.2 / Fusion 0.85.1 + agent 2.3.16, cela fonctionne puis en important la BDD de mon serveur de prod, Bim je me prend de nouveau la même erreur : "Erreur L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique"
  Reply
#10
ludof54 Wrote:J'ai testé avec une nouvelle installation à 0 sous Centos 7 64 bits avec GLPI 0.85.2 / Fusion 0.85.1 + agent 2.3.16, cela fonctionne puis en important la BDD de mon serveur de prod, Bim je me prend de nouveau la même erreur : "Erreur L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique"

toujours le même problème chez moi
  Reply
#11
Bonjour à tous,

Je rencontre également le même problème.

Ma config : VM Windows Serveur 2008R2, Xampp 1.7.7 avec apache : 2.2.21 et mysql : 5.5.16

GLPI 0.85.4 et Fusion inventory 0.85 +1.1 et l'agent 2.3.16

Donc pas de souci pour créer la tâche dans Fusion Inventory, la lancer en manuellement ou la laisser en automatique avec le le cron de glpi activé.

par contre elle reste toujours en cours alors que la découverte réseau est bien terminée, mais chose pour l'inventaire SNMP.

La tâche en cours d'execution et qui à ce moment là, a pourtant fini la découverte réseau :

[Image: 87caf3f3-114a-41fe-bf50-ea5711dea97a.jpg]

et à la fin du fichier log de l'agent j'ai : la response status 200.

De plus au niveau de l'agent il reste sur running task NetDiscovery.

Si je redémarre le service, la tâche passe en erreur et donc se termine.

J'ai testé GLPI 0.85.4 et Fusion inventory 0.85 +1.1 et l'agent 2.3.16 sur un Windows 7 sp1 avec une version d'apache et mysql plus récente, même problème.

J'ai aussi testé avec l'agent 2.3.15, 2.3.8, 2.3.5 et 2.2.7-4, cela ne fonctionne pas non plus.

Quelqu'un à t'il trouvé une solution de contournement ?

Bonne journée à tous

Cordialement

Gruik
  Reply
#12
j'ai le même problème je vais pas faire avancer le sujet mais j'ai deux questions :

J'ai la même version que toi (à part le serveur sous debian8) mais je ne trouve pas comment lancer la tache manuellement, tu parles également du cron glpi ...je vois pas de quoi tu parles pourrais éclairer ma lanterne ?
Merci
  Reply
#13
mla Wrote:j'ai le même problème je vais pas faire avancer le sujet mais j'ai deux questions :

J'ai la même version que toi (à part le serveur sous debian8) mais je ne trouve pas comment lancer la tache manuellement, tu parles également du cron glpi ...je vois pas de quoi tu parles pourrais éclairer ma lanterne ?
Merci

Bonjour Mla,

Pour lancer la tâche manuellement il faut aller dans configuration => Actions automatiques et tu prends l'action automatique taskscheduler et là tu fais exécuter, ainsi la tâche découverte réseau que tu auras paramétré dans fusion inventory sera en état préparé.

Ensuite tu lances l'agent manuellement soit par le menu démarrer => tous les programmes et FusionInventory Agent et le lien FusionInventory Agent Status ou tu vas dans ordinateur tu prends la machine qui va servir à faire la découverte réseau onglet FusInv Agent et tu lances.

Pour le cron de GLPI, il faut paramétrer une tâche planifié sur la machine qui héberge GLPI.

Cela donne ceci chez moi

[Image: 8d825595-c09e-4acb-9d59-02e2eb71b6d3.jpg]

Ainsi l'action automatique taskscheduler' sera exécuté en automatique et les autres aussi.

Cordialement

Gruik
  Reply
#14
Le lien pour créer une tâche planifiée

http://www.glpi-project.org/wiki/doku.ph...ig:crontab
  Reply
#15
Merci Gruik ...j'ai enfin ma tache en "préparé" ...je vais voir si le paquet s'installe au prochain inventaire.
  Reply
#16
Bonjour à tous,

J'ai du procédé à redémarrage du service afin que la tâche s'arrête et passe en erreur.

[Image: 5f098e1e-15b4-4d15-96a1-5adb4545ef65.jpg]

J'ai aussi installé l'agent en mode d’exécution tâche au lieu de service.

Cela va créer une tache planifiée au niveau du gestionnaire de tâche de Windows.

Une fois la tâche planifiée paramétrée elle exécute bien la tâche paramétrée dans Fusion Inventory mais elle ne s'arrête pas, elle reste toujours en cours.

Elle vas passer en erreur lorsque la tache planifiée suivante se lancera.

Toujours pas d'idée de votre côté ?

Bonne journée à tous

Cordialement

Gruik
  Reply
#17
Bonjour à tous,

Après une nouvelle tentative.

Avec la version 2.3.12 X86 et X64 cela fonctionne pour l'inventaire réseau lorsque l'on renseigne seulement une imprimante, j'ai la tâche qui se termine bien (SUCCES).

[Image: 546cec74-6769-4236-bd86-01ca3e575bd5.jpg]

par contre pour la découverte avec la version 2.3.12 X86 et X64 j'ai le service qui plante.

Cordialement

Gruik
  Reply
#18
Bonjour à tous,

Nouvelle tentative.

Avec l'agent 2.3.12 x64 en mode Tâche et non service, la découverte réseau a fonctionné avec (sur l'agent) le nombre de threads (découverte réseau) à 1 (par défaut).

[Image: c23572a3-e625-486c-87dc-a8101c5612c9.jpg]

Bonne journée à tous

Cordialement

Gruik
  Reply
#19
Bonjour

Toujours le meme problème avec les taches qui ne se terminent pas
agent 2.3.16 nouvelle version de fusioninventory 0.85+2
Merci

GLPI 0.90.5/ Plugins Fusion : 090+1.4 / Agent : 2.3.18 < Serveur Centos 64 Bits>
  Reply
#20
Sur quel OS?
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#21
Serveur sur une Centos 6 64 Bits
et agent sur un windows 2012 R2
Merci

GLPI 0.90.5/ Plugins Fusion : 090+1.4 / Agent : 2.3.18 < Serveur Centos 64 Bits>
  Reply
#22
Il y a un bug avec les threads sur les agents windows.
Donc pour le moment, soit utiliser un agent sous un autre os, soit désactiver l'inventaire local sur cet agent
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#23
Plus précisément ?

Désactiver l'inventaire local c'est reinstaller l'agent sans "Inventory"
mais cela ne peut se faire
l'installation ne permet pas de décocher ce choix , les autres Oui Netdiscovery , deploy ...
Merci

GLPI 0.90.5/ Plugins Fusion : 090+1.4 / Agent : 2.3.18 < Serveur Centos 64 Bits>
  Reply
#24
Bonjour,

Je pense que ddurieux veux parler de la désactivation du module inventaire directement dans la configuration de l'agent sur le serveur, mais j'ai le même problème et ça ne change rien, la tache de découverte ne se termine pas, comme si il n'arrivait pas à fermer tout les threads.
  Reply
#25
Bizarre, avec mes tests, la desactivation de l'inventaire local règle le soucis des threads
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)