Vanishing events - zmaudit over-enthusiasm?

lazyleopard · Post by **lazyleopard** » Fri Apr 01, 2005 8:03 pm

I was checking some stuff last night, and triggered a couple of cameras. Then I went to have a look at the just-created events. While I was looking at the "Stills" pages for one, it vanished. I don't think I hit any delet buttons. Looking at the log for zmaudit, I noticed the following:

Code: Select all

Database event '7/92874' does not exist in filesystem, deleting

and then, a little bit further down:

Code: Select all

Filesystem event '7/92874' does not exist in database, deleting

Note the first delete is, apparently, triggered by the lack of files in the filesystem, while the second is deletion of the filesystem event triggered by the lack of a database entry. Looks a bit like the first of those was premature. Anyone else seen anything like this, or was it just too late at night?

Post by **zoneminder** » Fri Apr 01, 2005 9:55 pm

We have a long running thread at http://www.zoneminder.com/forums/viewtopic.php?t=4139 about something which is probably the same issue. Currently it's not fully resolved.

Phil

lazyleopard · Post by **lazyleopard** » Sat Apr 02, 2005 5:38 pm

That does indeed look like a more severe manifestation of the same problem. The zmaudit patch linked is presumably for the 1.19.x version of zmaudit?

Post by **zoneminder** » Sun Apr 03, 2005 7:18 pm

Yes. The fix in it is included in 1.21.0 as well though so there must be some other issue that is causing zmaudit to think that events don't exist when they do.

Phil

lazyleopard · Post by **lazyleopard** » Mon Apr 04, 2005 12:46 pm

Ah... And I'm running 1.21.0... Oh well... Good hunting.

Post by **zoneminder** » Mon Apr 04, 2005 9:27 pm

If you have any clues or other observations as to why you lose certain events please feel free to post them here. As I don't appear to have this issue I'm a bit handicapped trying to track it down.

Phil

lazyleopard · Post by **lazyleopard** » Tue Apr 05, 2005 11:08 am

It's a tricky one. I've only noticed it the once. The pattern (zmaudit deleting the database event first because it's not in the file system, and then on the next iteration deleting the filesystem event because the database event's no longer there) is the same as the one observed in the 1.19.x thread. On the occasion I noticed it happening, the event being deleted was a very recent one (less than five minutes old).

I'd guess the most likely cause is zmaudit using a stale (cached?) copy of the events directory tree, but I've not had a good look at the code to see what it does yet. Does it perform any tricks to determine whether the directory tree needs re-reading? It might have problems if it relies on "atime", for instance...