¿Por qué inotifywatch no detecta cambios en los archivos agregados?

Estoy tratando de monitorear mi /tmpcarpeta en busca de cambios usando inotifywatch:

sudo inotifywatch -v -r /tmp

Después de crear un par de archivos ( touch /tmp/test-1 /tmp/test-2), termino inotifywatch(por Ctrl- lo Cque me muestra las siguientes estadísticas:

Establishing watches...
Setting up watch(es) on /tmp
OK, /tmp is now being watched.
Total of 39 watches.
Finished establishing watches, now collecting statistics.
total  attrib  close_write  open  create  filename
8      2       2            2     2       /tmp/

La salida solo imprime las estadísticas, pero no los archivos que esperaba (como aquí o aquí ). Probé diferentes tipos de acceso (a través de cat, mktemp, etc.), pero es la misma cosa.

¿Me he perdido algo? ¿Es porque estoy en VPS y algo ha sido restringido?

Sistema operativo: Debian 7.3 (inotify-tools) en VPS

Esto se debe a la forma en que está utilizando inotifywatchy a la forma en que funciona la herramienta. Cuando corres inotifywatch -r /tmp, comienzas a mirar /tmpy todos los archivos que ya están en él. Cuando crea un archivo en el interior /tmp, los metadatos del directorio se actualizan para contener el número de inodo del nuevo archivo, lo que significa que el cambio ocurre /tmp, no /tmp/test-1. Además, dado que /tmp/test-1no estaba allí cuando inotifywatchcomenzó, no hay ningún inotifyreloj puesto en él. Significa que no se detectará ningún evento que ocurra en un archivo creado después de colocar los relojes . Puede entenderlo mejor si lo ve usted mismo:

$ inotifywatch -rv /tmp &
Total of n watches.
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n

Si ha activado el mecanismo de rastreoinotify_add_watch(2) , el último comando le dará la cantidad de relojes configurados por inotifywatch. Este número debe ser el mismo que el dado por inotifywatchsí mismo. Ahora, cree un archivo dentro /tmpy verifique nuevamente:

$ inotifywatch -rv /tmp &
Total of n watches.
$ touch /tmp/test1.txt
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n

El número no habrá aumentado, lo que significa que el nuevo archivo no se ve. Tenga en cuenta que el comportamiento es diferente si crea un directorio en su lugar:

$ inotifywatch -rv /tmp &
Total of n watches.
$ mkdir /tmp/test1
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n + 1

Esto se debe a la forma en que -rse comporta el interruptor :

-r, --recursive: [...] Si se crean nuevos directorios dentro de directorios vigilados, se verán automáticamente.

^{Editar: Tengo un poco confundido entre sus dos ejemplos, pero en el primer caso , los relojes se colocan correctamente debido a las llamadas de los usuarios inotifywatchsobre ~/*(que se expande, ver el comentario de don_crissti aquí ). El directorio de inicio también se mira porque ~/.*contiene ~/.. Teóricamente, también debería contener ~/.., lo que, combinado con el -rinterruptor, debería dar como resultado la observación de todo el sistema.}

Sin embargo, es posible obtener el nombre del archivo que desencadena un evento de creación en un directorio observado, pero supongo inotifywatchque no recupera esta información (se guarda un poco más profundo que el nombre del directorio). inotify-toolsproporciona otra herramienta, llamada inotifywait, que puede comportarse más o menos como inotify-watch, y proporciona más opciones de salida (incluido %f, que es lo que está buscando aquí):

inotifywait -m --format "%e %f" /tmp

Desde la página del manual :

--format <fmt>Salida en un formato especificado por el usuario, utilizando sintaxis similar a printf. [...] Se admiten las siguientes conversiones:

%f: cuando ocurre un evento dentro de un directorio, este será reemplazado con el nombre del archivo que causó el evento .

%e: reemplazado por los eventos que ocurrieron, separados por comas.

Además, la -mopción (monitor) seguirá inotifywaitejecutándose después del primer evento, lo que reproducirá un comportamiento bastante similar al de inotifywatch's.