Tu as raison, je vais pousser mes investigations plus avant et modifier mon script balai et le lancer plus rapidement pour mettre en évidence le problème...
Pour la mécanique incrond...
Sur ta question en ce qui concerne incrond, je peux bien sur préciser les choses.
Mais je tiens à indiquer que la mécanique que je décris fonctionne très bien...
En fait, j'observe chaque dossier sur deux évènements en particulier IN_MOVETO et IN_CLOSEWRITE. Le pourquoi est simple et il est du à la manière dont les fichiers sont transférés par ftp...
Dans une version du logiciel distant qui transmet son fichier, le ftp est initié en créant un fichier file.tmp et à l'issue du téléchargement le fichier et renommer en file. C'est un peu ce qu'on observe quand FF télécharge un fichier ;-), à la différence près que FF crée le nom du fichier avec un contenu vide et le même nom avec une extension .tmp...
Dans ce cas de figure incrond sollicite 2 fois mon script de dispatch sur les 2 évènements.
1° fois lors de la fermeture IN_CLOSEWRITE pour le fichier file.tmp à l'issue du téléchargement. Le script ne fera rien car le format du nom de fichier ne correspond pas à ce qu'il cherche.
2° fois lors du renommage IN_MOVETO du précédent fichier juste après sa fermeture et qui vient de perdre son extension. Cela me garantie que le transfert est bien terminé, qu'il n'y aura plus de mouvements sur ce fichier et là il y a traitement.
Dans une seconde version du logiciel, le ftp est différent, le fichier est transmit mais sans l'usage de l'extension .tmp. La fermeture du fichier via l’évènement IN_CLOSEWRITE confirme la fin du transfert et donc incond ne sollicite qu'une seule fois mon script de dispatch qui traite bien sur le fichier car il n'a pas l’extension .tmp.
Que ce soit la méthode 1 ou la méthode 2, tous les fichiers sont traités correctement après qu'ils sont arrivés avec le bon format de nom du fichier et tout ça en parallèle !
Je tiens à préciser que je n'ai pas jugé bon d'avoir une incrontab différente par dossier en fonction de la version du logiciel en face. C'est plus simple quand on génère la incrontab malgré la petite perte d'énergie pour le premier IN_CLOSEWRITE de la 1° méthode...
La mécanique de mon script balai...
Maintenant mon script balai, à un comportement similaire au script de dispatch lancé par incrond à la différence près que lui ne sait pas si des fichiers sont arrivés.
Il est donc obligé de balayer tous les dossiers et rechercher leur présence.
Ici aussi, il a la même mécanique de protection et ignorera les fichiers dont l'extension .tmp est présente et traitera le fichier dans le cas contraire.
Mais le risque est qu'il prenne en charge un fichier qui n'aurait pas été dispatché assez rapidement par le script lancé par incrond...
D'où, mon test sur l'heure de création du fichier (%y de la commande stat) qui indique une arrivée très proche et donc une indication à mon script de ne rien faire...
Dans le cas d'une date d'arrivée assez ancienne il est fort à parier que incrond n'avait pas vu ce fichier et donc là je passe le balai...
En conclusion ...
Cette belle mécanique semble très bien marcher mais encore une fois, il arrive qu'un fichier soit traité par mon script balai alors qu'il ne devrait pas l'être :-(.
Je m'en suis rendu compte en lançant plusieurs fois d'affiler et dans 99% des cas il ne voit aucun fichiers car ils ont tous été pris en charge correctement par incrond.
J'ai observé que cela n'arrive uniquement que pour les dossiers dans lequel la méthode 2 du ftp est utilisée. Il a remarqué également quand cela se produit, j'ai un envoie important de ftp dans le dossier ce qui me fait penser qu'incrond est un peu plus lent pour la prise en charge...
Pour rajouter une "cerise sur le gâteau" :-) qui peut peut-être apporter un autre éclairage est que l'arborescence unix ou se produisent les évènements est sous drbd entre deux machines en normal/secours (ça aussi ça marche très bien)...
[^] # Re: changer la maniere de faire
Posté par piaff33z . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.
Tu as raison, je vais pousser mes investigations plus avant et modifier mon script balai et le lancer plus rapidement pour mettre en évidence le problème...
Pour la mécanique incrond...
Sur ta question en ce qui concerne incrond, je peux bien sur préciser les choses.
Mais je tiens à indiquer que la mécanique que je décris fonctionne très bien...
En fait, j'observe chaque dossier sur deux évènements en particulier IN_MOVETO et IN_CLOSEWRITE. Le pourquoi est simple et il est du à la manière dont les fichiers sont transférés par ftp...
Dans une version du logiciel distant qui transmet son fichier, le ftp est initié en créant un fichier file.tmp et à l'issue du téléchargement le fichier et renommer en file. C'est un peu ce qu'on observe quand FF télécharge un fichier ;-), à la différence près que FF crée le nom du fichier avec un contenu vide et le même nom avec une extension .tmp...
Dans ce cas de figure incrond sollicite 2 fois mon script de dispatch sur les 2 évènements.
Dans une seconde version du logiciel, le ftp est différent, le fichier est transmit mais sans l'usage de l'extension .tmp. La fermeture du fichier via l’évènement IN_CLOSEWRITE confirme la fin du transfert et donc incond ne sollicite qu'une seule fois mon script de dispatch qui traite bien sur le fichier car il n'a pas l’extension .tmp.
Que ce soit la méthode 1 ou la méthode 2, tous les fichiers sont traités correctement après qu'ils sont arrivés avec le bon format de nom du fichier et tout ça en parallèle !
Je tiens à préciser que je n'ai pas jugé bon d'avoir une incrontab différente par dossier en fonction de la version du logiciel en face. C'est plus simple quand on génère la incrontab malgré la petite perte d'énergie pour le premier IN_CLOSEWRITE de la 1° méthode...
La mécanique de mon script balai...
Maintenant mon script balai, à un comportement similaire au script de dispatch lancé par incrond à la différence près que lui ne sait pas si des fichiers sont arrivés.
Il est donc obligé de balayer tous les dossiers et rechercher leur présence.
Ici aussi, il a la même mécanique de protection et ignorera les fichiers dont l'extension .tmp est présente et traitera le fichier dans le cas contraire.
Mais le risque est qu'il prenne en charge un fichier qui n'aurait pas été dispatché assez rapidement par le script lancé par incrond...
D'où, mon test sur l'heure de création du fichier (%y de la commande stat) qui indique une arrivée très proche et donc une indication à mon script de ne rien faire...
Dans le cas d'une date d'arrivée assez ancienne il est fort à parier que incrond n'avait pas vu ce fichier et donc là je passe le balai...
En conclusion ...
Cette belle mécanique semble très bien marcher mais encore une fois, il arrive qu'un fichier soit traité par mon script balai alors qu'il ne devrait pas l'être :-(.
Je m'en suis rendu compte en lançant plusieurs fois d'affiler et dans 99% des cas il ne voit aucun fichiers car ils ont tous été pris en charge correctement par incrond.
J'ai observé que cela n'arrive uniquement que pour les dossiers dans lequel la méthode 2 du ftp est utilisée. Il a remarqué également quand cela se produit, j'ai un envoie important de ftp dans le dossier ce qui me fait penser qu'incrond est un peu plus lent pour la prise en charge...
Pour rajouter une "cerise sur le gâteau" :-) qui peut peut-être apporter un autre éclairage est que l'arborescence unix ou se produisent les évènements est sous drbd entre deux machines en normal/secours (ça aussi ça marche très bien)...