[Fusioninventory-devel] Acces concurrent à un fichier de log

[Guillaume Rousse]

Bonjour.

Voici mon problème épineux du jour. Dans le code de l'agent
fusioninventory, il y a un logger, qui supporte plusieurs backend, dont
un basé sur un fichier. Pour faire cours, voici le code actuel de la
branche de développement.

http://github.com/guillomovitch/fusioninventory-agent/blob/212713a598fb54548ae82e004b45c8e9c8458237/lib/FusionInventory/LoggerBackend/File.pm

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)

La question du jour est donc, est-il possible de rendre ce truc juste
suffisament robuste simplement ? Par simplement, j'entend sans sortir
l'artillerie lourde, du type POE ou Log4Perl, du moins immédiatement. Le
passage à POE est prévu pour la version suivante (mais ne résoudra
qu'une partie des problèmes, à moins d'imposer également des contraintes
aux taches filles).

Je viens de rajouter une utilisation de flock avant tout accès au
fichier, tant via stat() que via print(). D'après ma compréhension de
perldoc, ca devrait être suffisant pour garantir contre les deux
problèmes précédent, du moins en cas d'utilisation par deux processus
différents. J'avoue n'avoir aucune idée de ce qui se passe en cas
d'accès multi-thread...

Le patch est celui-ci:

http://github.com/guillomovitch/fusioninventory-agent/commit/394822b9ac245920bfef82e3b32d7aa7ca38ed68

Y a-t-il des meilleurs idées dans la salle ? Ah, j'oubliais une
contrainte, on doit aussi rester portable (il y a une version windows).
-- 
BOFH excuse #256:

You need to install an RTFM interface.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4251 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/fusioninventory-devel/attachments/20101011/87559313/attachment.bin>