ZoneMinder Forums

Posted: **Sun Mar 13, 2005 3:23 pm**

Aaaahhh this is a sweet look for sore eyes!

Configured zmaudit to run every 3 days, although this is day one, all events are there, we will see what happens on day 3 when it runs.

Regards!

Posted: **Mon Mar 14, 2005 3:44 pm**

I have a patch made up for this issue now, which I can mail you if you want to try it. Unfortunately as I don't get the problem I can't test it so you may be the only person who can validate it. I will run it here for a day or two just to make sure it doesn't delete all your events!

Phil

Posted: **Thu Mar 17, 2005 3:37 am**

Phil

I would like to tell you what happend on this setup today. The disk was slowly filling up and PurgeWhenFull was setup at 90% disk with 10 results. The disk went into 92% and the filter was not doing its job. I supposed that since 20 events were being created every 10 minutes and the filter was doing 10 events every 5 minutes perhaps I needed to push the results to 20 and I did and restarted ZM.

Upon a later visit the disk was still filling up, so decided to up results to 50, restart ZM and waited. Still a couple of hours later I found that the disk was still filling up, now at 95%. So modified results to 100 restarted and waited.

When I came back about an hour later the disk was at 88%, so I guessed it was working by then, but no... the disk slowly kept going down. At about 85% I returned the results to 20 and restarted the whole system. Well that did not do it either.

Down at about 75% I erased the PurgeWhenFull filter and restarted everything once again and waited. Well, events were being deleted anyway and the disk was still dropping.

At about 62% I took a look into the zmaudit.log file, which never crossed my mind into looking at since it was setup to run once every three days. Well there was the culprit. Events were just being deleted as follows:

Code: Select all

Filesystem event '12/1513' does not exist in database, deleting
Filesystem event '12/6809' does not exist in database, deleting
Filesystem event '12/10425' does not exist in database, deleting
Filesystem event '12/7097' does not exist in database, deleting
Filesystem event '12/8443' does not exist in database, deleting
Filesystem event '12/29716' does not exist in database, deleting

Lots of lines like the above (Note "12" at the 12/xxxx). After a restart of the system log changed to:

Code: Select all

Filesystem event '15/30228' does not exist in database, deleting
Filesystem event '15/25047' does not exist in database, deleting
Filesystem event '15/2907' does not exist in database, deleting
Filesystem event '15/180' does not exist in database, deleting
Filesystem event '15/7828' does not exist in database, deleting
Filesystem event '15/4337' does not exist in database, deleting
Filesystem event '15/24629' does not exist in database, deleting

Lots of deleting... note the "15"... and after another restart:

Code: Select all

Filesystem event '14/28462' does not exist in database, deleting
Filesystem event '14/3771' does not exist in database, deleting
Filesystem event '14/29310' does not exist in database, deleting
Filesystem event '14/11705' does not exist in database, deleting
Filesystem event '14/3445' does not exist in database, deleting
Filesystem event '14/29975' does not exist in database, deleting
Filesystem event '14/1627' does not exist in database, deleting

... and another restart:

Code: Select all

Filesystem event '8/6849' does not exist in database, deleting
Filesystem event '8/10296' does not exist in database, deleting
Filesystem event '8/5887' does not exist in database, deleting
Filesystem event '8/11170' does not exist in database, deleting
Filesystem event '8/25724' does not exist in database, deleting
Filesystem event '8/26844' does not exist in database, deleting

So of course I had to comment out the zmaudit execute command and finally the problem went away. Set the filter to 65% and still waiting to see if it works (which I am sure it will).

The thing is this is the second time I have this problem with PurgeWhenFull on this setup, at first filter seems to not be working, and after tweaks it starts doing its job, but what got me was why it kept on going non stop! As a matter of fact the first time I let it go and it did go all the way to 1% LOL

Phil I hope this could shed any more light if any on this zmaudit "bug".

Regards!

Posted: **Thu Mar 17, 2005 4:46 am**

What more than likely happened is with having zmaudit only running once every three days,
The purge filter would run and see that you had reached your set limit and remove the events from the database. If you have the defualt set of 300 seconds then every 300 seconds it would run and remove 10 or 20 results (what ever you had set at the time). Now zmaudit which is reponsible for actualy removeing the files is running only once every three days (259200 seconds meens that the filter has run 864 times in three days) so it would meet the filter criteria until zmaudit did it's job of syncing with the database. Depending on how long the criteria for the filter was met (Lets say 1 day for example the filter would run 288 times in 24 hours, if you have your filter results set to 10, thats 2880 events that would be removed from the database) It would continue to purge events from the database until the requirements are met (which will not happen till zmaudit runs). Then when you started zmaudit it was removing all the files that were no longer in the database.
Hope this helps make since.
What you may want to do is resave the purge filter and remove the check to delete files till the testing is done and or set the filter to run only once every 259200 seconds and set the results to however many events can occur in three days. Setting the disk percentage lower will only make things worse. The filter time should be the same or run less often than the audit.
Cheers,
Cordel

Posted: **Thu Mar 17, 2005 9:43 am**

I think Corey is correct. The filters just remove the DB entries (possibly even ignoring the FAST_DELETE flag, I shall check). I should have the zmaudit patch up very shortly now I think so hopefully that will address your problem and you can switch it back on.

Phil

Posted: **Thu Mar 17, 2005 6:42 pm**

Cordel

Thanks for jumping in!

Let me see if I got this straight if you please:

PurgeWhenFull "flags" deletion on the number of results configured in the filter but it is not until zmaudit kicks in that these flagged events are actually, physically, removed from the HD?

Perhaps this is why right now that I have PurgeWhenFull set to 20 events at 65% disk is doing nothing? (Console shows disk at 66%)

My guess too would be that there are still flagged events (and more geting this flag as time goes by) and that perhaps I should delete the filter because once the zmaudit patch is out a lot of other events will be erased?

You are correct on the math. I have 19 cameras times 6 events each per hour times 24 hours equals to 2736 events per day which accounts for about 7% of the disk. Zmaudit was running once every 3 days or 259200 seconds, yet it kicked in every time the system was restarted. Right now the filter is being ran every 300 seconds with 20 results which would "flag" 9600 events in 24 hours (I am not sure if this flag term I am using is correct).

By doing the math too, my guess would be that zmaudit should, if working properly, stop at a point where perhaps no more "deletion flags" were found, but on a previous occasion I had the disk wiped out of events completely.

I am sure Phil (thanks Phil!) should have a more clear view of what is happening as the Architect of this Matrix

Regards!

Posted: **Thu Mar 17, 2005 10:35 pm**

Eklectick wrote: You are correct on the math. I have 19 cameras times 6 events each per hour times 24 hours equals to 2736 events per day which accounts for about 7% of the disk. Zmaudit was running once every 3 days or 259200 seconds, yet it kicked in every time the system was restarted. Right now the filter is being ran every 300 seconds with 20 results which would "flag" 9600 events in 24 hours (I am not sure if this flag term I am using is correct).

So actually with those settings every 24 hours your filter removes 5760 events EVERY 24 HOURS from the database. You need to set zmfilters to run every three days as explained above or your system as it is doing will delete more events than it makes.

Posted: **Thu Mar 17, 2005 11:40 pm**

Is there a way to "un flag" the events?

Tried zmaudit for a while and as expected it keeps deleting files, my guess is if left alone will clear all events.

Regards!

Posted: **Fri Mar 18, 2005 12:20 am**

Unfotunatly, I think the filter job is to delete the events from the database. You might want to check and see how many events are in you database as compaired to what is in your event folders. There is no flag in the database.

Posted: **Fri Mar 18, 2005 5:04 pm**

I have made a patch for zmaudit.pl and put it here. It was a little fiddly as a lot has changed since 1.19.5 especially with regard to DB users etc. Also I am not convinced it will fix the problem. What it does (or at least should) do is not delete any database or filesystem event younger than 300 seconds. So if there is any kind of timing issue where the event has only been created in one place first it should correct that. That may not be the problem in this case though.

It's probably worth a try anyway, make sure you back up your existing zmaudit.pl.z first and remember to rerun zmconfig.pl -noi to generate the real perl script before remaking and reinstalling.

Phil

Posted: **Wed Mar 23, 2005 6:29 pm**

Hi Phil!

I did the installation of the patch but zmdc.log is reporting this:

Code: Select all

'zmfilter.pl' started at 05/03/18 22:47:33
'zmfilter.pl' starting at 05/03/18 22:47:33, pid = 423
'zmaudit.pl -d 900 -y' started at 05/03/18 22:47:34
'zmaudit.pl -d 900 -y' starting at 05/03/18 22:47:34, pid = 428
/usr/local/bin/zmaudit.pl: line 1: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 2: ---: command not found
/usr/local/bin/zmaudit.pl: line 3: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 4: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 5: ZM_PATH_WEB./.ZM_DIR_IMAGES: No such file or directory
/usr/local/bin/zmaudit.pl: line 6: ZM_PATH_WEB./.ZM_DIR_EVENTS: No such file or directory
/usr/local/bin/zmaudit.pl: line 7: ZM_PATH_LOGS./zmaudit.log: No such file or directory
/usr/local/bin/zmaudit.pl: line 8: 0: Permission denied
/usr/local/bin/zmaudit.pl: line 12: ---: command not found
/usr/local/bin/zmaudit.pl: line 13: ZM_PATH_WEB./.ZM_DIR_IMAGES: No such file or directory
/usr/local/bin/zmaudit.pl: line 14: ZM_PATH_WEB./.ZM_DIR_EVENTS: No such file or directory
/usr/local/bin/zmaudit.pl: line 15: ZM_PATH_LOGS./zmaudit.log: No such file or directory
/usr/local/bin/zmaudit.pl: line 16: 300: Permission denied
/usr/local/bin/zmaudit.pl: line 17: 1: Permission denied
/usr/local/bin/zmaudit.pl: line 21: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 22: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 23: ---: command not found
/usr/local/bin/zmaudit.pl: line 24: my: command not found
/usr/local/bin/zmaudit.pl: line 25: syntax error near unexpected token `do'
/usr/local/bin/zmaudit.pl: line 25: `  do'
'zmaudit.pl -d 900 -y' crashed at 05/03/18 22:47:36, exit status 2
'zmaudit.pl -d 900 -y' starting at 05/03/18 22:47:36, pid = 449
'zmaudit.pl -d 900 -y' started at 05/03/18 22:47:36
/usr/local/bin/zmaudit.pl: line 1: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 2: ---: command not found
/usr/local/bin/zmaudit.pl: line 3: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 4: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 5: ZM_PATH_WEB./.ZM_DIR_IMAGES: No such file or directory
/usr/local/bin/zmaudit.pl: line 6: ZM_PATH_WEB./.ZM_DIR_EVENTS: No such file or directory
/usr/local/bin/zmaudit.pl: line 7: ZM_PATH_LOGS./zmaudit.log: No such file or directory
/usr/local/bin/zmaudit.pl: line 8: 0: Permission denied
/usr/local/bin/zmaudit.pl: line 12: ---: command not found
/usr/local/bin/zmaudit.pl: line 13: ZM_PATH_WEB./.ZM_DIR_IMAGES: No such file or directory
/usr/local/bin/zmaudit.pl: line 14: ZM_PATH_WEB./.ZM_DIR_EVENTS: No such file or directory
/usr/local/bin/zmaudit.pl: line 15: ZM_PATH_LOGS./zmaudit.log: No such file or directory
/usr/local/bin/zmaudit.pl: line 16: 300: Permission denied
/usr/local/bin/zmaudit.pl: line 17: 1: Permission denied
/usr/local/bin/zmaudit.pl: line 21: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 22: cambozola.jar: command not found
/usr/local/bin/zmaudit.pl: line 23: ---: command not found
/usr/local/bin/zmaudit.pl: line 24: my: command not found
/usr/local/bin/zmaudit.pl: line 25: syntax error near unexpected token `do'
/usr/local/bin/zmaudit.pl: line 25: `  do'

Perhaps I omitted something upon the installation?

I know this is spoon feeding but I did this to install the patch:

First stopped zm at prompt with service zm stop
On the /usr/src/zm-1.19.5/scripts:
Backed up zmaudit.pl.z to zmaudit.pl.z.old
Copied the zmaudit.patch and renamed to zmaudit.pl.z
Up one directory to /usr/src/zm-1.19.5/ and did perl zmconfig.pl -noi
After that did a make
After that did a make install
and finally did a service zm start

Did I miss something?

Regards!

Posted: **Wed Mar 23, 2005 8:06 pm**

Yeah, it's a patch file and not the actual file.
you baked up the file is good. Now make a copy back to zmaudit.pl.z and put the patch file in the root of your build dir so that you are just below folder zm-1.19.5
run
patch -p0 zmaudit.patch
This makes the needed changes from with in the file.
Now you can build zm
Cheers,
Cordel

Posted: **Wed Mar 23, 2005 10:05 pm**

Cordel:

When I do a "patch -p0 zmaudit.patch" I never get prompt back after a long time, it does not show as to be doing something, I have to Ctrl-C to get prompt back.

I am doing this "patch -p0 zmaudit.patch" at /usr/src/zm-1.19.5/ where I gunzip zmaudit.patch.gz -d the file Phil sent me:

I would just like to go through the procedure if you please:
Copied the original zmaudit.pl.z to /usr/src/zm-1.19.5/scripts/ an then

+) service zm stop
+) zmaudit.patch.gz -d at /usr/src/zm-1.19.5/
+) patch -p0 zmaudit.patch <<<- Where I am havin trouble at
+) perl zmconfig.pl -noi at /usr/src/zm-1.19.5/
+) make at at /usr/src/zm-1.19.5/
+) make install at at /usr/src/zm-1.19.5/
+) service zm start
Done

Thanks in advance.

Regards!

Posted: **Wed Mar 23, 2005 10:28 pm**

Opps,
I left out a <
patch -p0 < zmaudit.patch

Posted: **Wed Mar 30, 2005 4:37 am**

Hi again!

Cordel:

"patch -p0 < zmaudit.patch" did the magic and got it now running, thanks!

Phil:

I installed the patch and left it running now for several days. I am happy to see too that the number of dropped events I have is much less than before but unfortunately still there.

Nevertheless I really think that that your patch is going in the right direction. The zmaudit.log right now shows the following, which I would consider normal to be for a system that has yet to reach the PurgeWhenFull filter, this piece of log repeated of course one after the other:

Code: Select all

Found database monitor '1', got 1889 events
Found database monitor '2', got 1889 events
Found database monitor '3', got 1888 events
Found database monitor '4', got 1889 events
Found database monitor '5', got 1888 events
Found database monitor '6', got 1733 events
Found database monitor '7', got 1889 events
Found database monitor '8', got 1888 events
Found database monitor '9', got 1887 events
Found database monitor '10', got 1887 events
Found database monitor '11', got 1888 events
Found database monitor '12', got 1888 events
Found database monitor '13', got 1888 events
Found database monitor '14', got 1888 events
Found database monitor '15', got 1887 events
Found database monitor '16', got 1884 events
Found database monitor '17', got 1888 events
Found database monitor '18', got 1887 events
Found database monitor '19', got 1888 events
Found filesystem monitor '1', got 1889 events
Found filesystem monitor '10', got 1887 events
Found filesystem monitor '11', got 1888 events
Found filesystem monitor '12', got 1888 events
Found filesystem monitor '13', got 1888 events
Found filesystem monitor '14', got 1888 events
Found filesystem monitor '15', got 1887 events
Found filesystem monitor '16', got 1884 events
Found filesystem monitor '17', got 1889 events
Found filesystem monitor '18', got 1888 events
Found filesystem monitor '19', got 1889 events
Found filesystem monitor '2', got 1890 events
Found filesystem monitor '3', got 1889 events
Found filesystem monitor '4', got 1890 events
Found filesystem monitor '5', got 1889 events
Found filesystem monitor '6', got 1734 events
Found filesystem monitor '7', got 1890 events
Found filesystem monitor '8', got 1889 events
Found filesystem monitor '9', got 1888 events

On some other pieces of the log I have found this, which I suppose is normal too, where some events are left "open" for zmaudit to "close":

Code: Select all

Found database monitor '1', got 1885 events
Found database monitor '2', got 1885 events
Found database monitor '3', got 1884 events
Found database monitor '4', got 1885 events
Found database monitor '5', got 1884 events
Found database monitor '6', got 1729 events
Found database monitor '7', got 1885 events
Found database monitor '8', got 1884 events
Found database monitor '9', got 1883 events
Found database monitor '10', got 1883 events
Found database monitor '11', got 1884 events
Found database monitor '12', got 1884 events
Found database monitor '13', got 1884 events
Found database monitor '14', got 1884 events
Found database monitor '15', got 1883 events
Found database monitor '16', got 1880 events
Found database monitor '17', got 1884 events
Found database monitor '18', got 1883 events
Found database monitor '19', got 1884 events
Found filesystem monitor '1', got 1885 events
Found filesystem monitor '10', got 1883 events
Found filesystem monitor '11', got 1884 events
Found filesystem monitor '12', got 1884 events
Found filesystem monitor '13', got 1884 events
Found filesystem monitor '14', got 1884 events
Found filesystem monitor '15', got 1883 events
Found filesystem monitor '16', got 1880 events
Found filesystem monitor '17', got 1884 events
Found filesystem monitor '18', got 1883 events
Found filesystem monitor '19', got 1884 events
Found filesystem monitor '2', got 1885 events
Found filesystem monitor '3', got 1884 events
Found filesystem monitor '4', got 1885 events
Found filesystem monitor '5', got 1884 events
Found filesystem monitor '6', got 1729 events
Found filesystem monitor '7', got 1885 events
Found filesystem monitor '8', got 1884 events
Found filesystem monitor '9', got 1883 events
Found open event '74810', closing
Found open event '74811', closing
Found open event '74812', closing
Found open event '74813', closing
Found open event '74814', closing
Found open event '74815', closing
Found open event '74816', closing
Found open event '74817', closing
Found open event '74818', closing
Found open event '74819', closing
Found open event '74820', closing
Found open event '74821', closing
Found open event '74822', closing
Found open event '74823', closing
Found open event '74824', closing
Found open event '74825', closing
Found open event '74826', closing
Found open event '74827', closing
Found open event '74828', closing

Yet unfortunately some hiccups still exist and do show in the log as the following shows:

Code: Select all

Found database monitor '1', got 1860 events
Found database monitor '2', got 1860 events
Found database monitor '3', got 1859 events
Found database monitor '4', got 1860 events
Found database monitor '5', got 1859 events
Found database monitor '6', got 1704 events
Found database monitor '7', got 1860 events
Found database monitor '8', got 1859 events
Found database monitor '9', got 1858 events
Found database monitor '10', got 1858 events
Found database monitor '11', got 1859 events
Found database monitor '12', got 1859 events
Found database monitor '13', got 1859 events
Found database monitor '14', got 1859 events
Found database monitor '15', got 1858 events
Found database monitor '16', got 1855 events
Found database monitor '17', got 1859 events
Found database monitor '18', got 1858 events
Found database monitor '19', got 1859 events
Found filesystem monitor '1', got 1860 events
Found filesystem monitor '10', got 1858 events
Found filesystem monitor '11', got 1859 events
Found filesystem monitor '12', got 1859 events
Found filesystem monitor '13', got 1859 events
Found filesystem monitor '14', got 1859 events
Found filesystem monitor '15', got 1858 events
Found filesystem monitor '16', got 1856 events
Found filesystem monitor '17', got 1859 events
Found filesystem monitor '18', got 1858 events
Found filesystem monitor '19', got 1859 events
Found filesystem monitor '2', got 1860 events
Found filesystem monitor '3', got 1859 events
Found filesystem monitor '4', got 1860 events
Found filesystem monitor '5', got 1859 events
Found filesystem monitor '6', got 1704 events
Found filesystem monitor '7', got 1860 events
Found filesystem monitor '8', got 1859 events
Found filesystem monitor '9', got 1859 events
Filesystem event '9/74279' does not exist in database, deleting
Filesystem event '16/74281' does not exist in database, deleting
Found open event '74335', closing
Found open event '74336', closing
Found open event '74337', closing
Found open event '74338', closing
Found open event '74339', closing
Found open event '74340', closing
Found open event '74341', closing
Found open event '74342', closing
Found open event '74343', closing
Found open event '74344', closing
Found open event '74345', closing
Found open event '74346', closing
Found open event '74347', closing
Found open event '74348', closing
Found open event '74349', closing
Found open event '74350', closing
Found open event '74351', closing
Found open event '74352', closing
Found open event '74353', closing

...where the deleted events show up to be dropped from the daily count.

Phil, I understand that you tweaked zmaudit to not delete any database or filesystem event younger than 300 seconds. Since events are being created every 600 seconds (from the hour exactly every ten minutes) and zmaudit is ran every 900 seconds (but not every fifteen minutes on the hour much rather to every fifteen minutes since the last restart) perhaps this timing thing is still overlapping in some way with some events that still get the axe.

Do you think perhaps a tweak on the "younger than 300 seconds" (knowing that every 600 seconds, nineteen events are created) could render a 100% non drop result and if so which way would you recommend to go (more than or less than 300)?

Regards!

P.S. If your recommendation were to be to play with this 300 second time, would you please tell me what file is the correct one to edit to the new value and if a "make" and "make install" procedure is to be done.

ZoneMinder Forums

Axis cameras on time lapse with dropped events