piaff33z a écrit 9 commentaires

  • [^] # Re: ftp et antivirus

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.

    J'y avais pensé, avec une sorte de procédure de fin de transfert. Mais c'est pas l'option que j'ai prise. Le serveur que j'utilise est PRO_FTPD.

    Je trouvais la solution incrond assez élégante et surtout capable de m'ouvrir d'autres usages futures…

  • [^] # Re: changer la maniere de faire

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.

    Le script de traitement ne sera pas plus long, il n'a pas vocation à l'être. Mais je note que ta remarque a du sens.

    Maintenant sur cette solution, elle me convient très bien et elle m'évite justement de gérer la création et la suppression de fichiers lock qui à mon sens est bien plus lourde mais peut-être pour toi plus déterministe => J'en conviens mais question de point de vue ;-)

    Dans mon cas, si tout tourne bien avec incrond, il n'est pas nécessaire de gérer des lock car chaque fichier transféré dans les dossiers de réception est bien pris en charge individuellement donc il n'y a pas de concurrence d'accès à un fichier à un moment donné en condition normal de fonctionnement.

    Mon soucis est dans des contextes très particuliers
    - à la suite d'un arrêt ou reboot du service incrond
    - d'une maintenance programmée
    - un dossier qui n'a pas été sous surveillance incrond ( pour maintenance )
    - …

    Dans ces cas, il me faut un script balai qui arrive à deviner s'il ne va pas traiter un fichier qui pourrait être pris en charge par incrond.

    Le temps de détection pour moi est arbitraire, je l'ai mis à 1 min mais j'aurai bien pu mettre 10 min si j'ai peur de rentrer en collision avec incrond.

  • [^] # Re: changer la maniere de faire

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.

    Bonjour la "cantonnade" comme promis je poste la solution que j'ai trouvé :-) et si ça peut aider quelqu'un à jour…

    Pour rappel mon soucis provenait du fait de la disparition d'un fichier qui est en paramètre de la commande ci-dessous :

    stat -c %y $file | sed s/\\..*$//

    Cette commande est sensée retourner l'heure de création du fichier. Mais encore une fois si le fichier a disparu la commande stat va se planter !

    • Phase 1 - J'isole le problème éventuel de la disparition du fichier.
    stat -c %y $file 2>/dev/null | sed s/\\..*$//
    • Phase 2 - Je traite le fait que cette commande peut ne rien renvoyer si le fichier a disparu. Dans ce cas-ci, j'aurai besoin qu'on me renvoie now. Pour cela, j'utilise la commande ifne dont une implémentation shell pourrait être la suivante.
    ifne () { read line && echo ${line:-$(eval "$@")} || eval "$@" ; }

    Cette commande est programmée pour recevoir en entrée un flot :
    * si ce flot n'est pas nul, elle l'affiche via un echo
    * Si ce flot est nul ou s'il y a un problème en entrée elle évaluera l'ensemble des paramètres comme une seule instruction.

    Dans mon contexte cela devient :

    stat -c %y $file 2>/dev/null | sed s/\\..*$// | ifne echo now

    Maintenant l'insertion totale dans ma condition décrite précédemment :

    ...
    IGNORE_TIME=1
    # Test qui va marcher à tous les coups même si $file est vide...
     [[ $File =~ ^regexp_qui_valide_name_file$ ]] && (( $(diff_date now "$(stat -c %y $file 2>/dev/null | sed s/\\..*$// | ifne echo now)" m) > $IGNORE_TIME )) && {
      ...
      # Prise en charge du fichier
      ...
      }

    Et voili, voilà ça marche comme un charme. J'avoue ça donne un peu le torticolis :-)

    Merci encore aux différentes participations même si c'est moi qui est trouvé la soluce ;-)

  • [^] # Re: changer la maniere de faire

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.

    J'ai modifié mon script balai pour isoler la condition et j'ai trouvé ou était le problème en le lançant plusieurs fois d'affilé.
    J'avais raison, le stat se plante parce que le fichier a disparu !

    Par contre le plantage du stat valide la condition !!!! :-(

    Je vais travailler ce point et faire en sorte que la condition renvoie faux dans ce contexte !!!

    En tout cas merci à NeOX et ptit_poulet d'avoir participé à ce fil…

    Ps : Je posterai ma solution ;-)

  • [^] # Re: changer la maniere de faire

    Posté par  . 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.

      • 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: Syncthing ?

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.

    Je connais pas mais cela me semble peut-être un peu "too much" pour ce que je veux faire ;-)

    Me besoin doit se contenter d'utiliser au maximum d'outils déjà présents sur un système Linux standard.

    Incron était déjà un "addone" qui m'a semblé vraiment intéressant et simple à rajouter.

    En tout cas merci pour cette idée, j'étudierai peut-être plus profondément cet outil pour découvrir toutes ses possibilités…

  • [^] # Re: changer la maniere de faire

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1. Dernière modification le 05/03/17 à 14:48.

    J'ose espérer que d'autres méthodes puissent exister que le lock ;-)

    Sur ta solution d'éliminer le process concurrent, c'est une solution mais entre le laps de temps ou tu lances à nouveau incrond et le moment ou il sera totalement opérationnel, tu pourras avoir quelques fichiers qui peuvent passer entre les mailles du filet surtout si les transferts sont nombreux ce qui est mon cas et tu retombes un peu sur le même problème…

    Mais sans vouloir obstinément trouver "autre manière de faire" pourquoi ne pas objectivement regarder ce bout de code et voir où le problème pourrait se situer ? :-)

    En tout cas merci de participer à ce débat ;-)

  • [^] # Re: changer la maniere de faire

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1.

     # Test ci-dessous qui pose problème de temps en temps...
      [[ $File =~ ^regexp_qui_valide_name_file$ ]] && (( $(diff_date now "$(stat -c %y $File} | sed s/\\..*$//)" m) > $IGNORE_TIME )) && {
      ...
      # Prise en charge du fichier
      ...
      }

    => La variable $File est statique et son contenu ne peut pas varier. Elle a été alimentée à la suite d'un ls dans une boucle. Donc la RegExp va forcément bien se réaliser.

    => Mais, je me suis posé la question de savoir si au moment ou je faisais le test de la date avec stat si le fichier serait encore présent et dans le contraire comment se comporterait la condition !?

    Peut-être que mon problème est ici. Néanmoins, si cela devait arriver je devrais avoir une erreur en retour de la commande stat qui devrait dans ce cas-ci planter ma condition !

    Pourtant mon script ne me retourne pas d'erreur à ce moment là :-( mais plus loin quand il essaye de dispatcher le fichier qui n'est plus là :-(

  • [^] # Re: changer la maniere de faire

    Posté par  . En réponse au message J'ai une colle pour les experts shell ou système.. Évalué à 1. Dernière modification le 05/03/17 à 10:53.

    J'aimerai éviter le principe de lock, je trouve ça lourd à gérer et en plus il faudrait le faire pour chaque fichier reçu :-(… Le calcul d'une date me parait bien plus simple, non !?

    mais pourquoi incrond serait arrété ? c'est un daemon systeme, au meme titre que crond,

    Et pourquoi pas, à cause d'une maintenance ou autre…
    J'ai peut-être pas précisé mais le script balai pourrait être lancé à la main et pas forcément par cron.
    Justement après une opération de maintenance pour faire le ménage des dossiers de réception et traiter les fichiers qui ne l'auraient pas été…