Running a private net for your cams? Consider installing ntpd to serve them

Add any particular hints or tricks you have found to help with your ZoneMinder experience.
Post Reply
jwarfin
Posts: 11
Joined: Mon Jul 23, 2018 4:36 am

Running a private net for your cams? Consider installing ntpd to serve them

Post by jwarfin » Sat Aug 04, 2018 7:59 pm

So, I tripped over this issue recently & I thought I'd share info on it.

I recently setup a new 1.30.4 ZM system on Xubuntu 18.04. For various reasons, I chose to setup a private net for the cams. In essence: added a gigabit NIC to the server, established a private subnet for it and hooked the cams up to it via a dedicated POE switch. In my case, cam config of the actual cams could only be done via a Windows app. So, I had to temporarily put the cams on the LAN net to do that. In any case, the cams work great on the private net. But I discovered something after a while...

The cams could not reach a time server and this caused them to hammer the private net with constant retries. The private net is a non-routable subnet, so I knew the cams couldn't sync - I didn't really care about that. But I didn't expect them to NEVER give up retrying on time sync and rapidly flood the NIC with retry packets. Other devices I've used in this kind of scenario will give up on time sync after a few failed attempts and then attempt retrying every few hours of so. Not the case with my cams.

I discovered this situation by running "iftop -n -P" for the private net port on the server. This showed the constant ntp retry packets.

So I setup an ntpd server (actually, chrony) on the ZM server and configured it to allow client time sync from the private cam net. This made the cams happy and eliminated the ntp retry storm on the private net. This reduced load on the NIC and, as a result, reduced the system load factor by about .10. Bonus!

jwarfin
Posts: 11
Joined: Mon Jul 23, 2018 4:36 am

Re: Running a private net for your cams? Consider installing ntpd to serve them

Post by jwarfin » Sat Aug 11, 2018 10:20 pm

Kind of a follow-up to my first post.

It turns out that chronyd will go offline & exit if the network drops. It's a feature, not a bug. The man page hints at the reason behind this. So, it's typical to mitigate this by setting up an hourly cron script to restart chronyd if it's inactive/dead. The ZM setup I'm implementing on is 1.30.4 on Ubuntu 18.04. I implemented the chronyd watchdog this way:

Created /etc/cron.hourly/chrony_watchdog script. Contents:

Code: Select all

#!/bin/sh -e

/usr/local/bin/restart_chrony_if_inactive
Created /usr/local/bin/restart_chrony_if_inactive. Contents:

Code: Select all

#!/bin/bash

CHK=`systemctl is-active chrony | grep -c inactive`

if [ $CHK -eq 1 ]; then
	systemctl restart chrony
	logger -t CHRONY_WATCHDOG "Chrony inactive, restarted" 
fi

exit

Both scripts are owned by root and mode 755. They have to be executable or anacron/cron won't run them.

Once implemented, chronyd will be checked to see if it's running. If not, it will be restarted and the restart will be logged to syslog.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest