Bonjour. J'ai été confronté au même problème, il n'y a pas si longtemps. Je l'ai résolu en attribuant des time-slots à mes scripts. C'est à dire que mes scripts ne pouvaient accéder au fichier de log que durant une période donnée (1s toutes les 1,5s). Pour ma défense, mes scripts prenaient entre 8 et 12 heures à l'exécution et je n'étais pas à 10 minutes près.
Le 13 octobre 2010 10:56, Guillaume Rousse <[email protected]> a écrit : > Le 13/10/2010 09:32, Kevin Hinault a écrit : > > Le 11 octobre 2010 23:57, Guillaume Rousse <[email protected]> a > écrit : > >> Bonjour. > >> > >> > >> C'est joli tout plein, mais voilà, l'agent est relativement parallélisé. > >> Et comme on ne se refuse rien, il utilise à la fois du multi-thread > >> (pour gérer son interface web, si nécessaire) et du multi-processus > >> (pour lancer ses taches, s'il tourne sous forme de démon). Et ce genre > >> de situations peut aboutir à deux problèmes: > >> - une corruption du fichier, pour le cas d'écriture simultanée > >> - un mauvais fonctionnement du mécanisme de surveillance automatique de > >> la taille du fichier, avec apparement un intervenant qui efface un > >> fichier, tandis qu'un autre garde le descripteur correspondant à > >> l'ancien... (http://forge.fusioninventory.org/issues/406) > > > > D'habitude je lis les messages de la liste plutôt que d'y répondre car > > ce que j'y vois est d'un niveau bien supérieur au moins mais pour une > > fois j'ai l'impression de pouvoir répondre. Je suis peut être à côté > > de la plaque (tu jugeras) mais pour gérer les accès concurrents > > multi-thread, multi-processus, ne serait-il pas plus efficient de les > > rediriger vers un processus type démon qui ne servirait qu'à ça ? Ca > > demande de mettre une communication client/serveur mais dans ce cas, > > seul le serveur aurait le loisir de logger les messages et comme il > > serait assez simple, il serait aussi robuste aux plantages. > Tu as parfaitement raison. Le seul problème, c'est que ca ne correspond > à la contrainte 'bidouille temporaire, même si totalement inefficace, en > attendant un vrai changement d'architecture'... > > -- > BOFH excuse #299: > > The data on your hard drive is out of balance. > > > _______________________________________________ > Perl mailing list > [email protected] > http://listes.mongueurs.net/mailman/listinfo/perl > > -- dimitry Ernot membre du projet JNS http://jacknsee.sourceforge.net/ membre du projet Ktopsy http://sourceforge.net/projects/ktopsy/
_______________________________________________ Fusioninventory-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/fusioninventory-devel
