Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

cpierron · 2008-02-29 17:13:13

- OpenSuse 10.3 (Linux 2.6.22.16-0.2)
- Apache 2.2.4
- PHP 5.2.5
- MySQL Ver 14.12 Distrib 5.0.45
- Glpi 0.70.2
- OcsNg 4100
- Mass_ocs_import 1.1
- Installation récente.

Bonjour,

Mass_Ocs_Import paramétré comme suit :

Activer les traces : Oui
Mise à jour des informations toutes les : 10 machine(s)
Afficher les processus où rien n'a été modifié : Non
Effacer les processus après : 1 heures
Nombre de secondes pour le rafraichissement des pages (0 pas de rafraichissement) : 0 sec
Effacer les processus vides après 0 heures
Nombre maximum de machines à importer par thread : 0
Serveur OCS par défaut : Tous les serveurs
Prévenir si machines non importées : Oui
Nombre de machines : 0

Dans l'écran des traces d'imports (Plugins -> Import en masse OCS),
je vois apparaitre :

* les processus détaillés de la dernière heure.
* les statistiques de la dernière heure.
* et (problème) tous les processus datant de plus d'une heure.

En fait, les processus de plus d'une heure ne sont pas purgés.

Je pensais que ce nettoyage se faisait automatiquement, à chaque fois que le chargement s'effectue.

Dans le code source il y a bien une fonction cronDeleteThreads, mais apparemment elle n'est appelée nulle part.

Une idée ?
Merci

Last edited by cpierron (2008-03-05 15:26:27)

cpierron · 2008-03-10 11:18:21

Avant que je ne me lance dans du code spécifique pour purger les process,
j'aimerais savoir si c'est normal que le code prévu à cet effet dans le plugin ne soit jamais actif.

Ou alors je ne vois pas par quel mécanisme la fonction cron_plugin_mass_ocs_import() de plugins/mass_ocs_import/setup.php devrait être appelée ?

remi · 2008-03-10 13:04:55

Modifie la valeur :
Effacer les processus vides après 0 heures => 1 heure

0 c'est conservation sans limite il me semble.

La fonction de nettoyage est appelée par le cron interne à GLPI.

Pour que les stats soient correctes et utilisables, il est préférable de mettre la même valeur au 2 (de toute manière les stats ne seront calculées que le la plus petite période de conservation).

++

cpierron · 2008-03-10 15:52:42

Bonjour Remi
Merci pour la réponse.

Malheureusement, j'avais déjà fait cette modif (remettre tout à 2 heures) la semaine dernière, mais sans effet.

En fait, j'ai l'impression que la fonction de nettoyage n'est jamais appelée ?
Comment GLPI "sait-il" qu'il doit appeler la fonction de nettoyage du plugin ?

Est-ce inscrit dans un fichier de config -> j'en ai pas trouvé ?
Est-ce inscrit dans une table ? Non plus ?

Last edited by cpierron (2008-03-10 15:53:58)

remi · 2008-03-10 17:49:19

Non, c'est en dur dans le code du plugin.

$PLUGIN_HOOKS['cron']['mass_ocs_import'] = HOUR_TIMESTAMP;

Il enregistre un "cron" (1 fois par heure) qui sera appeler par le coeur de GLPI.

Donc il faut qu'il y ait des visites sur l'application pour déclencher le nettoyage (comme les autres cron internes).

Donc il faut attendre au moins 1 heure après la modif de config.
Ou supprimer le fichier files/_lock/mass_ocs_import.lock

Généralement, il reste aussi toujours quelques enregistrement en dessous des stats, c'est normal.
Chez nous ça marche bien...

++

Last edited by remi (2008-03-10 17:52:33)

cpierron · 2008-03-11 09:55:25

Merci.
Effectivement, ça marche quand on navigue dans l'application pendant un long moment.

C'est dommage qu'il n'y ait rien de prévu pour pouvoir "stimuler" la cron GLPI depuis la crontab.
(ça serait quand même mieux pour ceux qui ont le contrôle de leur serveur).

Last edited by cpierron (2008-03-11 10:25:41)

remi · 2008-03-11 14:25:15

Si, c'est possible.

Une petite recherche dans les archives du forum te donnera rapidement la solution.

A+

cpierron · 2008-03-13 09:48:00

Malheureusement, même en appelant la page "cron.php" depuis la crontab, il ne se passe rien.
*/5 * * * * php ~http/glpi_pro/front/cron.php

Il faut réellement naviguer dans l'appli pendant longtemps pour que le pseudo-cron (qui porte bien son nom) se réveille.

Dans d'autres posts il est mentionné d'intégrer cet appel depuis la "crontab apache", mais ça n'existe pas ! La crontab, c'est au niveau unix, pas apache.

Je jette l'éponge, et me lance dans des deletes "manuels".
Merci quand même.

remi · 2008-03-13 12:36:15

Tu peux créer un crontab pour chaque utilisateur Unix.

Le service "httpd" utilise un compte utilisateur "apache" (Redhat/Fedora et autres) ou "www-data" (debian et autres).

Personnellement, je préfère créer un fichier dans cron.d

Ex : /etc/cron.d/glpi

*/5 * * * * apache php /chemin/vers/glpi/front/cron.php

A noter : la colonne supplémentaire contenant le nom d'utilisateur et le chemin complet.

++

Last edited by remi (2008-03-13 12:36:50)

Forum GLPI-Project

Announcement

#1 2008-02-29 17:13:13

Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#2 2008-03-10 11:18:21

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#3 2008-03-10 13:04:55

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#4 2008-03-10 15:52:42

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#5 2008-03-10 17:49:19

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#6 2008-03-11 09:55:25

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#7 2008-03-11 14:25:15

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#8 2008-03-13 09:48:00

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

#9 2008-03-13 12:36:15

Re: Mass_ocs_import ne supprime pas automatiquement ses anciennes traces.

Board footer