Hy guys,
Few weeks ago, I´ve performed a upgrade do 1.36.33, after that my servers start to run out of disk space.
I set up 2 storage areas that is mointed over glusterfs clusters.
Some time server save events on gluster mount but sometimes writes at the default storage location.
How can I debug this issue?
My storage configuration:
For example in monitor 76
Most events are stored in glusterfs volume
[fred_m@zoneminder00 76]$ pwd
/mnt/zoneminder_pool02/zoneminder/events/76
[fred_m@zoneminder00 76]$ ls
2023-05-03 2023-05-04 2023-05-05 2023-05-06 2023-05-08 2023-05-09 2023-05-10 2023-05-11 2023-05-12
Events stored at default volume that fill all my disk space
[root@zoneminder87 76]# pwd
/var/lib/zoneminder/events/76
[root@zoneminder87 76]# ls
2023-05-11 2023-05-12
Storage issue on 1.36.33
Re: Storage issue on 1.36.33
Look in your logs. There are probably errors message explaining why.
Are the events all from one monitor? Perhaps it is simply set to store there.
Are the events all from one monitor? Perhaps it is simply set to store there.
Re: Storage issue on 1.36.33
Which log file do you suggest to check ?
This issue is present on all monitors.
Thanks,
This issue is present on all monitors.
Thanks,
-
- Posts: 110
- Joined: Sun Nov 15, 2015 7:19 pm
Re: Storage issue on 1.36.33
I had this issue before when I converted to using an SSD for the OS. I had to delete the default storage location so it is never available as an alternate storage location.
It appears if there is any kind of error that prevents writing to another storage area it will fallback to the default if it's an available storage location
It appears if there is any kind of error that prevents writing to another storage area it will fallback to the default if it's an available storage location
Re: Storage issue on 1.36.33
Yes, I just had this happen on a server after one of the 5 hdds unmounted/failed. It defaults to /var/cache/zoneminder/events, and then as a result, fills up the root hdd, and then mysql won't load. I wrote something on it here:lightguy48 wrote: ↑Wed May 24, 2023 1:05 am I had this issue before when I converted to using an SSD for the OS. I had to delete the default storage location so it is never available as an alternate storage location.
It appears if there is any kind of error that prevents writing to another storage area it will fallback to the default if it's an available storage location
https://wiki.zoneminder.com/Using_a_ded ... orage_Area
I don't want to ask the devs to do more work, but this seems like something that should be addressed. Has this been considered as a bug for 1.37? Expected behavior, would I'd guess be, that if the storage area fails, for the cameras to not record anything at all, instead of filling up any/default available hdd space.
fastest way to test streams:
ffmpeg -i rtsp://<user>:<pass>@<ipaddress>:554/path ./output.mp4 (if terminal only)
ffplay rtsp://<user>:<pass>@<ipaddress>:554/path (gui)
find paths on ispydb or in zm hcl
If you are new to security software, read:
https://wiki.zoneminder.com/Dummies_Guide
ffmpeg -i rtsp://<user>:<pass>@<ipaddress>:554/path ./output.mp4 (if terminal only)
ffplay rtsp://<user>:<pass>@<ipaddress>:554/path (gui)
find paths on ispydb or in zm hcl
If you are new to security software, read:
https://wiki.zoneminder.com/Dummies_Guide