in reply to Fresh eyes - linux::Inotify2 event delays

Unfortunately, I don't see anything fishy at the first sight.

I usually don't use Linux::Inotify2 (there were some problems installing it, IIRC), I just 

open my $inotify, '-|',
    do { no warnings 'qw';
         qw( inotifywait -m -r -e close_write -e moved_to --exclude /\
+.git/|~$|/#[^/]+# . ) }
    or die $!;

while (<$inotify>) {
    my ($path, $event, $file) = split;
    ...

[download]

It seems you ignore IN_MOVED_TO while I react to it. Maybe it can be the problem, or not?

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Replies are listed 'Best First'.
Re^2: Fresh eyes - linux::Inotify2 event delays
by ghenry (Vicar) on Apr 06, 2022 at 14:19 UTC

    Thanks for taking the time to read and reply. Nah, we are watching folders that FreeSWITCH creates mp3 files in and only IN_CLOSE_WRITE is of interest when it closes the file descriptor.

    It's a tricky one. I'm going to dig into 'retry' and maybe try your way too.

[reply]

      Just to offer a negative data point: we're doing something similar to your use case at $work, that is, we rely on inotify to postprocess call recordings that were finished by Asterisk, monitoring IN_CLOSE_WRITE events, just like you, and to my knowledge we've never seen such random delays in receiving events during the 3+ years this system has been in production. However, in our case the user side inotify implementation is in Go.

      What kernel version do you use? That may be relevant.

[reply]

        Found it. Our retry is in blocking mode and the CDR it is trying to find does not ever exist (normally there is a delay to them showing up). Once the retry fully expires, ->poll() does the next read on the file descriptors and picks up all the queued events. There are not many events, so no overruns (missed events) and linux just leaves them there for collection when ready. It wasn't my code :-)

[reply]

        This is on a CentOS 7 NAS. The files are getting written to it over an NFS share, but watching on the NAS file system side. Kernel 3.10.0-1160.59.1.el7.x86_64. The python inotify has no issues it seems. We might switch to inotifywait like @choroba says and like another dept at $work uses. Or switch to C or Go. Very strange. Again, we get all the events and it feels like they are flushed to us. I might ditch retry and go to ->read. We're playing with the python version to pop UUIDs into a Redis FIFO/queue and move find_call_details() and email_recording() into separate program to speak to Redis.

[reply]

In Section Seekers of Perl Wisdom