Por que inutilizar os eventos são acionados mais de uma vez?

Question

Esta questão surge de outra que eu coloquei em Stackoverflow . Estou usando o Watcher - os mesmos problemas se aplicam a Incron - para monitorar uma pasta e suas pastas filhas quanto a mudanças e silenciosamente esquecê-las do Dropbox.

Eu monitore o evento write_close - IN_CLOSE_WRITE - para o propósito. Originalmente, eu assisti ao evento modify , ou seja, IN_MODIFY. Enquanto isso funcionou, descobri que ao escrever arquivos grandes, ele dispararia mais de uma vez. Isso soou justo, então mudei para IN_CLOSE_WRITE , pois achei que seria razoavelmente justo supor que, para um determinado arquivo, isso só ocorreria uma vez.

No entanto, esse não é o caso. Mesmo para um arquivo de texto muito pequeno - apenas um caractere - criado no Nano, o evento ocorre duas vezes. Na melhor das hipóteses, isso pode resultar em tráfego desnecessário quando o mesmo arquivo é sincronizado no Dropbox duas vezes. No meu caso, isso leva ao desastre, pois no primeiro evento eu faço a sincronização e, em seguida, excluo o arquivo do lado do servidor. O resultado - no segundo evento, o arquivo secundário do Dropbox se torna um arquivo de 0 bytes.

Estou lidando com isso por enquanto, fazendo meu script de sincronização dormir por 10s antes de fazer qualquer outra coisa e depois verificar que o arquivo em questão ainda existe antes de tentar a sincronização do Dropbox. Isso funciona porque na segunda iteração o arquivo está faltando e o script termina.

Isso soa hackeado na melhor das hipóteses. Talvez não seja um hack ruim, mas eu prefiro entender - por que mesmo o evento IN_CLOSE_WRITE ocorre mais de uma vez?

Algumas informações adicionais

• Verifique se não há várias instâncias do observador em execução.

Saída de ps ax|grep watcher.py

23880 ?        Sl     0:01 python /usr/local/bin/watcher.py restart
24977 pts/0    S+     0:00 grep --color=auto watcher.py

O sistema de arquivos é ext4 . Eu devo mencionar que eu encontrei precisamente o mesmo problema com o Incron. Eu inicio o daemon do Watcher a partir de um script em lote executado via /etc/rc2.d . O Incron OTH inicializa sem qualquer problema comigo por meio de sua instalação apt-get install incron padrão.

A essência do meu arquivo watcher.ini é mostrada abaixo.

[DEFAULT]
logfile=/var/log/watcher.log
pidfile=/var/run/watcher.pid

[job1]
watch=/path/to/watch

events=write_close
excluded=
recursive=true
autoadd=true

command=/home/datastore.php $filename

Reduzi o script datastore.php para o essencial para verificar se ele é disparado duas vezes sem nenhum dos meus bagunçados uploads do Dropbox + código de exclusão da fonte.

#! /usr/bin/php
<?php
file_put_contents('/tmp/watcher',$argv[1],FILE_APPEND);

?>

Eu, então, criei um pequeno arquivo no caminho em questão e, em seguida, examinei /tmp/watcher . O problema ainda persiste - o arquivo ainda tem duas entradas sucessivas para $argv[1] .

    

Answer 1

Eu não tenho representante suficiente para postar isso como um comentário, mas você tem certeza de que arquivos temporários, possivelmente ocultos, não estão sendo criados? Eu tive um problema semelhante com inotifywait disparando várias vezes, mas percebi que era porque o vim criava um arquivo .swp ao editar, o que acionaria um evento ao fechar. Também pegaria o evento close do arquivo original.

Parece que você está percebendo o evento disparando vários arquivos no mesmo arquivo, o que não é algo que eu consegui reproduzir - isso só aconteceria uma vez para o arquivo temporário e uma vez para o original. / p>

Eu tentei um teste rápido com o nano e não acho que ele crie um arquivo temporário (pelo menos para o caso de poucos caracteres), mas há algo mais em sua configuração que possa depender de um comportamento semelhante?

    

Answer 2

Não tenho certeza, mas provavelmente o primeiro write_close grava atributos de arquivo nele, como tempo de criação, e somente depois disso ele grava dados reais. Na verdade, o rsync cria um arquivo temporário e, quando tudo é feito, ele move o arquivo temporário para o arquivo real na mesma pasta, de modo que é fácil monitorar normalmente quando você usa o rsync, e mover é uma operação atômica. Por outro lado, há algo que um tiro no inotify, provavelmente que usando isso, podemos acionar algo na primeira mensagem de modificação, e como você sugeriu dormir por um período razoável de tempo antes de iniciar a operação. Estou cavando isso agora e atualizarei quando encontrar algo novo. link