Page 1 of 1

How to restart ZM service in response to camera dead?

Posted: Tue Jun 06, 2017 5:41 am
by xcxeon
So, I am currently running a 4 camera setup, all using ffmpeg, and I have a very annoying issue.

Occasionally, one or more of my cameras will loose connection to wifi for a moment, and when it reconnects, zoneminder does not restart it properly. The only way I can get it to start working again is to disable/enable the camera, or click 'status' and 'restart'.

I've googled around for weeks now and tried everything I could find, but nothing has worked, so at this point, I would like to use a cronjob to service zoneminder restart when this happens, but, I need to know how to determine if my cameras are working in that context. I considering parsing logs, but that was no help, they are too chatty and there are no discernible errors (that dont normally appear anyway) indicating a camera has gone dead.

How can I determine if one of the cameras is no longer recording, and restart zm in response?

Re: How to restart ZM service in response to camera dead?

Posted: Wed Jun 07, 2017 7:05 pm
by vox
If you don't drop a better solution, you can restart ZM each hour via cron. If you drop how to restart only when camera not reconnect properly, please share :)

For restart 1x by hour :

Edit crontab add after all
  • Code: Select all

                    # debug zoneminder
    30 * * * *                      /opt/scripts/restartZM.sh
    30 => each 30th minute of the hour
Creat the script Add in
  • Code: Select all

    #!/bin/bash
    #sleep +-57 secondes is necessary for don't distrub MoCord and Record (don't creat events of few secondes)
    sleep 57
    sudo service zoneminder restart
    tape CTRL+X for save&quit

Re: How to restart ZM service in response to camera dead?

Posted: Thu Jun 08, 2017 1:51 am
by iconnor
I would be tempted to use monit to ping the camera and if it goes offline then do a zmdc.pl restart zmc -m whatever.

but really... ZM should restart the camera automatically. It is supposed to. There is a zmwatch.pl program that looks for the last time zmc or zma did anything and if it more than some seconds (like 30 or so, it is configurable) then it restarts the camera.

What type of zm monitor is it?

Re: How to restart ZM service in response to camera dead?

Posted: Thu Jun 08, 2017 7:26 pm
by snake
I had a similar issue. Changing the zmwatch timeout (options - config) from the default of 10 seconds to a higher number, say 30 or 60 fixed most of my dropout issues.

If the cameras still drop out after that, you can monitor the zmwatch.pl watchdog script by either putting it in debug log mode or adding additional logging in the perl code itself to see where the hangup is. The perl code is easy to understand so don't be afraid to take a look.

Re: How to restart ZM service in response to camera dead?

Posted: Thu Apr 19, 2018 1:47 am
by alabamatoy
snake wrote: Thu Jun 08, 2017 7:26 pm I had a similar issue. Changing the zmwatch timeout (options - config) from the default of 10 seconds to a higher number, say 30 or 60 fixed most of my dropout issues.
I am running version 1.30.0, and there is no zmwatch timeout option that I am able to find. Is this a later version option? Its not on options/config AFAICT, unless its called something totally unrelated. Its also not described in the documentation here http://zoneminder.readthedocs.io/en/sta ... onfig.html

Where is this setting?

Re: How to restart ZM service in response to camera dead?

Posted: Sat Apr 21, 2018 4:13 pm
by snake
alabamatoy wrote: Thu Apr 19, 2018 1:47 am I am running version 1.30.0, and there is no zmwatch timeout option that I am able to find.
I didn't give enough information, it's the zmdc setting in options. zmwatch is a watchdog script and if you read it, it will use zmdc.pl to restart any cameras that are not responding. The setting is MAX_RESTART_DELAY. Note that I ended up making this script as I am still receiving dropouts that zmdc can't repair. But with the script, my system is operational and repairs cameras without manual intervention, albeit with slight delay.

More of an issue in 1.29 than 1.30. In 1.28 they used to return on their own.