• Build alternative tools fsfnotifywait and fsnotifywatch
• The alternative tools use fanotify instead of inotify on new kernels (>=v5.9)
• The alternative tools enable watching an entire filesystem without setting up recursive watches
• Setting up fanotify filesystem watches require admin privileges

Hi,

First, thank you for a great set of tools. Right now, I'm using inotifywait in this format:

!/bin/sh

/usr/bin/inotifywait -mrq -e delete /var/www | while read file; do # log deleted file done

I noticed that inotifywait offers the option -d that allows to daemonize it. However, when I use it, I lose completely the monitoring functionality so my while loop is useless.

In a perfect world, inotifywait will allow me to execute an unlimited number of commands specified in a directory (i.e. /etc/inotifywait.d) where I can create many .conf files containing a structure similar to: rq /var/www attrib,delete executeprogram

where "rq" represents a recursive action with quiet mode enabled, "/var/www" a directory watched, "attrib,delete" the inotify events and "executeprogram" a program/function to execute when the notified event occurs. Then, inotifywait could be daemonized with an init script and will automatically execute the commands found in those config files.

Could you tell me if there is a way to actually do that now with inotifywait? Right now I use a shell wrapper as binary to execute the above tasks but I would very much like to use the daemon (-d) option available into inotifywait.

I guess, this is more a request than an issue. Would it be possible to have an option where we can specify the program to execute while the inotify event occurs? inotifywait -dq -e modify -x "kdialog --msgbox 'Apache needs love!'" /var/log/messages

where -x is the program to execute. Still, it would require a directory where you can insert your config files containing all your commands... so we are back to the previous requested functionality.

Thank you for your support.

inotifywait -q /var/log/everything/current used to output /var/log/everything/current MODIFY but now outputs /var/log/everything/ MODIFY.

From man page:

The  event  output can be configured, but by default it consists of lines of the following form:

       watched_filename EVENT_NAMES event_filename

Is this a bug or does the man page need to be updated to reflect new behavior?

Hello,

I can't seem to get the latest master to to build and test on a fresh Ubuntu Xenial docker image.

The result of:

./build_and_test.sh

is:

....
ok 1 - Exit code 0 is returned
ok 1 - Exit code 2 is returned
# passed all 1 test(s)
1..1
# passed all 1 test(s)
1..1
not ok 1 - event logged
ok 1 - Exit code 2 is returned
ok 1 - event logged
#
#	    run_ &&
#	    grep ATTRIB $logfile
#
# passed all 1 test(s)
1..1
# passed all 1 test(s)
1..1
# failed 1 among 1 test(s)
1..1
Makefile:38: recipe for target 'inotifywait-daemon-logs-chown.t' failed
make[1]: *** [inotifywait-daemon-logs-chown.t] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/inotify-tools-orig/t'
Makefile:31: recipe for target 'test' failed
make: *** [test] Error 2

Hoping to get to the bottom of this so I can write some other tests.

Thanks

The --format and --timefmt options don't appear to interpret \0 or similar. This severely limits the usefulness of this tool in applications that require safely reading arbitrarily named files.

Hi, Is it possible to include inode number of watched resource in event log? So inotifywait -m output would be similar to:

/tmp/ CREATE test 529561
/tmp/ DELETE test 529561

where 529561 is the inode number of test file. I am building database where these numbers are crucial and such feature would be really helpful. Thanks

Running inotifywait 3.22.1.0 on Ubuntu 22.04, I observed a bug apparently due to a bad file descriptor:

$ inotifywait -e modify foo
Setting up watches.
Couldn't watch foo: Bad file descriptor

I could also reproduce with the master branch. Investigating further, it appears that inotifytools_init() in inotifytools.c exits immediately after entry, because the global variable init is non-null, even though we just called it at the beginning of inotifywait.c's main(), and the global variable is supposed to be initialised at 0.

Bisecting showed that this variable used to be static, but was changed at some point to non-static to share it with stats.c, and this is where the bug first occurs. As far as I understand, the symbol conflicts with the init() function from the program's entry point. When entering inotifytools_init(), it seems that the value for that function is picked up and compared to 0, found non-null, and the initialization function exits, leaving inotify_fd uninitialized (-1) and a bad file descriptor.

Renaming the variable to something other than init is enough to fix the bug.

$ ./src/inotifywait -e modify foo
Setting up watches.
Watches established
<waits>

Fixes: dd59c5347af8 ("Extract stats into their own file (#129)")

Hello,

The examples should recommend best practices. However, inotifywait examples don't work when filenames has space characters. I am not sure exactly how to correct the bug. But this might work:

inotifywait -m -r -e create --format "%e%w%f" /some/folders |
while read output; do
  case "$output" in
    CREATE,ISDIR*)
      fullpath=${output#CREATE,ISDIR}
      echo "$0: $fullpath"
      ;;
  esac
done

Hi, I'm using inotify-tools to watch for completed file uploads (via ftp). So, I'm using inotifywait from a shell script to pass a set of directories (around 200 directories) to be watched for event CLOSE_WRITE.

I'm seeing many events are not being received at all. And for many files, events are received very late (2/3 hours to a day late).

Any idea what could be wrong here?

I'm using RHEL V6.2 with following kernel version - 2.6.32-220.23.1

Any help here is appreciated.

Thank you.

Hi guys,

I'm trying to install inotify-tools on an ubuntu machine 20.04.

I tried first to use install it using

sudo apt-get install inotify-tools

but I got the error:

Couldn't initialize inotify. Are you running Linux 2.6.13 or later, and was the CONFIG_INOTIFY option enabled when your kernel was compiled? If so, something mysterious has gone wrong. Please e-mail [email protected] and mention that you saw this message.

Since I couldn't find a solution to this problem, I'm trying to install it from source, version 3.22.1.0, I used the following steps:

./autogen.sh
./configure --prefix=/usr --libdir=/lib64
make
make check  # the test passes
sudo make install

during the last step, I got the following warnings:

[...]
libtool: warning: remember to run 'libtool --finish /directory/lib'
[...]
make[2]: Entering directory '/home/vongola/Downloads/inotify-tools-3.22.1.0/src'
 /usr/bin/mkdir -p '/usr/bin'
  /bin/bash ../libtool   --mode=install /usr/bin/install -c inotifywait inotifywatch '/usr/bin'
libtool: warning: '../libinotifytools/src/libinotifytools.la' has not been installed in '/directory/lib'
libtool: install: /usr/bin/install -c .libs/inotifywait /usr/bin/inotifywait
libtool: warning: '../libinotifytools/src/libinotifytools.la' has not been installed in '/directory/lib'
libtool: install: /usr/bin/install -c .libs/inotifywatch /usr/bin/inotifywatch

so I ran the command

libtool --finish /directory/lib

But in vain, since when I run inotifywait, I got:

inotifywait: symbol lookup error: inotifywait: undefined symbol: inotifytools_filename_from_event

How can I solve this please?

Thank you in advance!

Hi,

we've extracted some parts concerning the file access event stats into their own file during the course of a scientific study. We want to check with whether this extraction seems sensible for you.

Hi @ericcurtin,

Thanks for your work. I am the maintainer of the inotify-tools on Debian.

Debian warns about library in inotify-tools is declaring the stack as executable[1].

[1] https://udd.debian.org/lintian/?packages=inotify-tools

From the lintian system[2]:

The listed shared library declares the stack as executable.

Executable stack is usually an error as it is only needed if the code contains GCC trampolines or similar constructs which uses code on the stack. One possible source for false positives are object files built from assembler files which don't define a proper .note.GNU-stack section.

To see the permissions on the stack, run readelf -l on the shared library and look for the program header of type GNU_STACK. In the flag column, there should not be an E flag set.

[2] https://lintian.debian.org/tags/executable-stack-in-shared-library

Running 'readelf -l libinotifytools.so.0' I can see:

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
[...]
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10

Thanks for your attention.

Eriberto

I am using the latest release (3.22.6.0) and am having issues with the --include option. If I create a subdirectory in a watched directory, file creation events don't get logged if a file that matches the --include regex pattern was created in that new subdirectory (unless the subdirectory also matches the --include regex pattern). I also provide the -r option for recursive watching. This happens in both daemon and monitor mode:

inotifywait -r -d -o /path/to/outfilename.log -e create --include "\.bin$" /path/to/dirtowatch
mkdir /path/to/dirtowatch/newdir # Does not get logged
mkdir /path/to/dirtowatch/newdir.bin # Does get logged
touch /path/to/dirtowatch/newdir/file.bin # Does NOT get logged, even though file.bin matches --include regex pattern
touch /path/to/dirtowatch/newdir.bin/file.bin # Does get logged, maybe because newdir.bin was logged?

Is this because file/directory creation events that don't match the --include pattern are completely discarded, hence any new files created in new unmatched subdirectories are not logged?

Also, when I run in daemon mode (-d) with an outfile specified (-o), it does not automatically create the file if it doesn't exist. There are no issues when I switch to monitor mode (-m). Here is an example command:

inotifywait -r -d -o /path/to/outfilename.log -e create /path/to/dirtowatch

This error appears when I run the above command:

No such file or directory: /path/to/outfilename.log

If I create /path/to/outfilename.log before starting inotifywait, this error doesn't appear. Is this normal behavior?

Hi, I tried to write a bash script to monitor the file changes in the smb network disk mounted on the server. Then, I found a problem. When I use the server to operate on the files, inotifywait can output the log information normally. However, if I use other hosts mounted on the same network disk to operate on the files on the disk, inotifywait seems to be unresponsive. Does this mean that inotifywait only reads the logs of file system operations on the local machine? Is there a way around this problem? Or is there another tool that can do this kind of monitoring? Thank you very much!

I wrote a script to watch multiple directories: https://github.com/voncloft/Voncloft-Search/blob/master/voogle/new-scripts/searchengine.sh

The script inside that script I am having an issue with is: https://github.com/voncloft/Voncloft-Search/blob/master/voogle/new-scripts/add.sh

Whenever I execute code on my system for mkdir -pv for example

I would like for it to execute for a/b/c ...not just the last folder

Thanks

mkdir -pv /temp/a/b/c (a does not exist) only "c" will be logged a and b are not put into mysql database at all.

Am I doing something wrong?

For my purpose use case, I only need to know when a file gets modified so I run inotifywait in a loop with what needs to be done when the monitored file gets modified. I have no use for the output line so it'd be nice if I could get rid of it altogether. I tried setting --format to an emptry string with --no-newline but inotifywait wasn't having it. Not a truly necessary feature as I can redirect the output to /dev/null but nonetheless it would make this a slightly less complex.