monitor stops recording events
Posted: Wed May 12, 2004 7:52 pm
Hi Phil an all,
I have a system in service with 6 cameras, all in modect mode. Occasionally one or more cameras will stop recording events. Different camera(s) each time.This can happen after a day or two of uptime or a couple of weeks. Streaming from these cameras continues to work. If "force alarm" is selected, the "cancel forced alarm" link appears, but the monitor does not go into alarm status, and no event is generated. In this condition attemting to restart ZM hangs. No errors in syslog. "service zm restart" "zmpkg.pl restart" or from the web interface just hang, no error messages.
If the machine is rebooted, everything comes back up working properly. I have hacked the MySQL init script to check and repair all tables on startup. I suspect a database problem is the cause, or possibly a hung zma proccess? This problem has persisted through a couple of ZM upgrades, currently 1.19.3. Debugging this sytem is difficult as I have no remote access and working on it involves a 45 minute drive. The owner is generally anxious to get it back up quickly so he reboots it and it is working correctly when I am able to work on it.
Has anyone else seen this behavior? Suggestions for debugging?
Regards,
Ross
I have a system in service with 6 cameras, all in modect mode. Occasionally one or more cameras will stop recording events. Different camera(s) each time.This can happen after a day or two of uptime or a couple of weeks. Streaming from these cameras continues to work. If "force alarm" is selected, the "cancel forced alarm" link appears, but the monitor does not go into alarm status, and no event is generated. In this condition attemting to restart ZM hangs. No errors in syslog. "service zm restart" "zmpkg.pl restart" or from the web interface just hang, no error messages.
If the machine is rebooted, everything comes back up working properly. I have hacked the MySQL init script to check and repair all tables on startup. I suspect a database problem is the cause, or possibly a hung zma proccess? This problem has persisted through a couple of ZM upgrades, currently 1.19.3. Debugging this sytem is difficult as I have no remote access and working on it involves a 45 minute drive. The owner is generally anxious to get it back up quickly so he reboots it and it is working correctly when I am able to work on it.
Has anyone else seen this behavior? Suggestions for debugging?
Regards,
Ross