You can just list directories you want to observe:
$ inotifywait testdir1 testdir2/ -m
Inside application, after instance of inotify is created using inotify_init() function, inotify_add_watch() can be called several times for selected paths. You can find the system limit of watching paths in /proc/sys/fs/inotify/max_user_watches
(8192 by default).
I think your approach is correct, and tracking the cookie is a robust way of doing this.
However, the only place in the source of inotify-tools (3.14) that cookie
is referenced is in the header defining the struct
to match the kernel API.
If you like living on the edge, this patch (issue #72) applies cleanly to 3.14 and adds a %c
format specifier for the event cookie in hex:
--- libinotifytools/src/inotifytools.c.orig 2014-10-23 18:05:24.000000000 +0100
+++ libinotifytools/src/inotifytools.c 2014-10-23 18:15:47.000000000 +0100
@@ -1881,6 +1881,12 @@
continue;
}
+ if ( ch1 == 'c' ) {
+ ind += snprintf( &out[ind], size-ind, "%x", event->cookie);
+ ++i;
+ continue;
+ }
+
if ( ch1 == 'e' ) {
eventstr = inotifytools_event_to_str( event->mask );
strncpy( &out[ind], eventstr, size - ind );
This change modifies libinotifytools.so
, not the inotifywait
binary. To test before installation:
LD_PRELOAD=./libinotifytools/src/.libs/libinotifytools.so.0.4.1 \
inotifywait --format="%c %e %f" -m -e move /tmp/test
Setting up watches.
Watches established.
40ff8 MOVED_FROM b
40ff8 MOVED_TO a
Assuming that MOVED_FROM always occurs before MOVED_TO (it does, see fsnotify_move()
, and it's an ordered queue, though independent moves might get interleaved) in your script you cache the details when you see a MOVED_FROM line (perhaps in an associative array indexed by ID), and run your processing when you see a MOVED_TO with the matching half of the information.
declare -A cache
inotifywait --format="%c %e %f" -m -e move /tmp/test |
while read id event file; do
if [ "$event" = "MOVED_FROM" ]; then
cache[$id]=$file
fi
if [ "$event" = "MOVED_TO" ]; then
if [ "${cache[$id]}" ]; then
echo "processing ..."
unset cache[$id]
else
echo "mismatch for $id"
fi
fi
done
(With three threads running to shuffle a pair of files each 10,000 times, I never saw a single out of order event, or event interleaving. It may depend on filesystem and other conditions of course.)
Best Answer
Although the inotify FAQ implies partial support:
it does not actually say what might be supported (or in which kernel version, since that's mostly down to the inotify support in the filesystem itself rather than the library/utilities).
A simple explanation is that is doesn't really make sense to support inotify for everything in in
/sys
(or/proc
) since they don't get modified in the conventional sense. Most of these files/directories represent a snapshot of kernel state at the time you view them.Think of
/proc/uptime
as a simple example, it contains the uptime accurate to the centisecond. Should inotify notify you 100 times a second that it was "written" to? Apart from not being very useful, it would be both a performance issue and a tricky problem to solve since nothing is generating inotify events on behalf of these fictional "writes". Within the kernel inotify works at the filesystem API level.The situation then is that some things in sysfs and procfs do generate inotify events,
/proc/uptime
for example will tell you when it has been accessed (access, open, close), but on my kernel/proc/mounts
shows no events at all when file systems are mounted and unmounted.Here's Greg Kroah-Hartman's take on it:
http://linux-fsdevel.vger.kernel.narkive.com/u0qmXPFK/inotify-sysfs and Linus:
http://www.spinics.net/lists/linux-fsdevel/msg73955.html
(both threads from 2014 however)
To solve your immediate problem you may be able to use dbus, e.g.
dbus-monitor --monitor --system
(no need to be root) will show trigger on tun devices being created and removed (though mine doesn't show the tun device name, only the HAL string with the PtP IP);udevadm monitor
(no need to be root); or fall back to polling the directory (try: script to monitor for new files in a shared folder (windows host, linux guest)). (Withudev
you could also useinotifywait -m -r /dev/.udev
and watch out for files starting with "n", but that's quite an ungly hack.)