PurgeWhenFull stops working

[lightguy48]

Just curious if anyone has had an issue where PurgeWhenFull will stop working?

About once a year or so it will happen, it's happened on 1.32.x and now again on 1.34.x. Everything will be going along fine for months on end and then one day I will notice I can't connect to the website and when I jump in via terminal I find the drive filled up to capacity several days earlier.

In the past I have just purged all entries in the DB and then clear out the old folders in the var/zoneminder/events

Thanks

[bbunge]

Do you have opt_fast_delete enabled? If so disable it. I have also found after years of use to set the full percentage to 85% This will give a bit of a cushion to allow the delete function to work. You can also set the number of files to delete to more than the 100 default value.

[lightguy48]

Yes, it's enabled, I've turned it off.

Yeah a year or so ago when this last happened I lowered my threshold to 85% because I figured that it had gotten too high with too little time to delete.

I will see what happens.

[lightguy48]

So this evening I noticed my system was up at 91% and was fairly unresponsive.

I'm finding these errors in my log but I'm not entirely sure what it's saying is wrong with the filter:

Can't execute filter 'SELECT E.*, unix_timestamp(E.StartTime) as Time, M.Name as MonitorName, M.DefaultRate, M.DefaultScale FROM Events as E INNER JOIN Monitors as M on M.Id = E.MonitorId LEFT JOIN Storage as S on S.Id = E.StorageId WHERE (E.EndTime IS NOT NULL) AND ( E.AlarmFrames < -2 weeks and E.Archived = 0 ) ORDER BY E.Id ASC LIMIT 0,10', ignoring: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'weeks and E.Archived = 0 ) ORDER BY E.Id ASC LIMIT 0,10' at line 9

[lightguy48]

I deleted what I think was the troublesome filter although it looked to be correctly formatted and the error has gone away.

I also made the purge when full filter run concurrently thinking maybe it if it runs in its own space it might work better which is what I understand the concurrently option does.

[mikb]

"E.AlarmFrames < -2 weeks "

This makes no sense to me, it might to you

If AlarmFrames is a count of how many frames are "alarmworthy", then what is the meaning of "< -2 weeks"?

It would be odd to have less than -2 alarmed frames, wouldn't "0" be a real-world minimum there?

I think maybe something confused got into your filtering settings (maybe < -2 weeks, meaning "more than 2 weeks old" should have applied to alarm start time?)

Either way, the SQL "You might want to check your syntax around ...." looks bang on. You might want to check it as above.

[lightguy48]

Yeah that's why I deleted the filter, not sure why -2 weeks would apply to alarm frames, it makes sense for a date (start or end)

I wonder if this was some how causing issues with the purge when full and it couldn't run properly.