ev_stat inotify implementation might miss events
yoann.v at prelude-ids.com
Tue Jan 26 17:05:41 CET 2010
Le mardi 26 janvier 2010 à 16:23 +0100, Marc Lehmann a écrit :
> On Tue, Jan 26, 2010 at 09:40:19AM +0100, Yoann Vandoorselaere <yoann.v at prelude-ids.com> wrote:
> > As I understand it, inotify guarantee that you'll get an event for every
> > changes on the file.
> That is impossible unless you make everything synchronous, so inotify
> cannot guarantee it.
Again, as I understand it, Inotify events are generated at syscall
levels, so they are synchronous to a syscall.
>From the Inotify manpage:
"If successive output inotify events produced on the inotify file
descriptor are identical (same wd, mask, cookie, and name) then they are
coalesced into a single event if the older event has not yet
been read (but see BUGS)."
For the record, the Linux auditing subsystem rely on Inotify.
> > This is not a problem if there is no more event queued for the given wd;
> > but in the other case, if there are multiple events queued, then the
> > infy_cb loop is going to continue calling infy_wd() with the *old* watch
> > descriptor.
> That doesn't matter, as we have the new watcher in place, so no events
> will be lost (modulo kernel bugs).
> i.e. even if there is a bug in inotify causing atcual events for the old
> id, we will receive the same events for the new id (again, barring bugs in
> the kernel).
If inotify already reported the event, I don't think it will update the
WD associated with it. Theses event are already stored in the userspace
buffer declared by libev, and you cannot expect the Kernel to update the
WD associated with event that you have already read().
infy_cb() loop through the events, and call infy_wd(), which will
sucessfuly lookup the first event. However, since libev registered WD is
changed at this point, the second iteration of infy_wd() won't find the
correct ev_stat handler.
> > > libev needs to rearm inotify after a change, as the event might have
> > > changed the path.
> > Are you talking about file renaming/deletion?s
> > If you are, I might have some suggestion on other way to handle that.
> Sure, I don't see any - afaics you have to change watchers. At best you
> can make an optimisation for certain events, but changing is required in
> general, as the path changes.
It would be interesting for libev to provide the ability to keep
monitoring the file until no application reference it anymore
In Prelude-LML we would like to handle deletion the following way:
If the file has been deleted but is still referenced by others
applications, then continue monitoring it, and open a new ev_stat()
handler in case any application re-create the filesystem file.
Yoann Vandoorselaere | Directeur Technique/CTO | PreludeIDS Technologies
Tel: +33 (0)1 40 24 65 10 Fax: +33 (0)1 40 24 65 28
More information about the libev