I think this might be more about my expectation than anything else but I am struggling to get ntpclient to work (on an openwrt-based box).
It is configured to update every 600s but my clock is drifting by about 2s/day so there's clearly no corrections taking place every 10 minutes, and if left for a week it just continues to accumulate so I don't think it's doing anything at all. But I don't really know what to expect.
I'm measuring the drift using ntpclient -c 1 -h 0.openwrt.pool.ntp.org .. so I know it has access to the NTP servers if it chooses to use them,
Any suggestions? When I google I find details on setting things like freq for far greater accuracy than I care about (a second or two out is fine by me as long as it isn't accumulating). I'd rather not move away from ntpclient as that's what's baked into the openwrt firmware I'm using and I'm trying to avoid making unnecessary changes, but I just can't get this to work. (I'm sure ntpclient -s in crontab would fix it but surely that isn't supposed to be necessary?)
On Wed, 23 Feb 2022 13:05:39 +0000 Mark Rogers mark@more-solutions.co.uk wrote:
I think this might be more about my expectation than anything else but I am struggling to get ntpclient to work (on an openwrt-based box).
It is configured to update every 600s [...]
How is it configured to do that?
Are you sure ntpclient is still running and hasn't been killed off by process limits, oom-killer or something else?
Hope that helps,
On Wed, 23 Feb 2022 at 14:10, MJ Ray mjr@phonecoop.coop wrote:
It is configured to update every 600s [...]
How is it configured to do that?
This is part of my problem in that I'm not sure I know the answer.
I mean the web interface of the unit says it is set to 600. If I look in /etc/config/ntpclient it's set to 600. But I don't know how that gets passed to ntpclient.
Are you sure ntpclient is still running and hasn't been killed off by process limits, oom-killer or something else?
There doesn't seem to be any process running called ntpclient but again I don't really know what to expect to see. I can't see anything in the busybox logs to indicate that the client is dying. I think the lack of any running ntpclient process is a clue though...
On Wed, 23 Feb 2022 14:56:26 +0000 Mark Rogers mark@more-solutions.co.uk wrote:
I mean the web interface of the unit says it is set to 600. If I look in /etc/config/ntpclient it's set to 600. But I don't know how that gets passed to ntpclient.
Often things in /etc/config get looked up as defaults, or sometimes passed there by cron jobs or init.d scripts (or I suppose systemd units now).
There seem to be at least five forks of ntpclient around! I wonder which one openwrt is using and what's meant to start it up. I don't remember openwrt well enough.
I think you're right that the lack of ntpclient process is the basic problem.
Regards,
On Wed, 2 Mar 2022 at 19:25, MJ Ray mjr@phonecoop.coop wrote:
Often things in /etc/config get looked up as defaults, or sometimes passed there by cron jobs or init.d scripts (or I suppose systemd units now).
At least on this box it's init.d.
Looking at the changes in the test firmware they seem to relate to the network startup, in that /etc/hotplug.d/iface/20-ntpclient (present previously, which reloaded ntpclient on interface up) was supplemented with a similar /etc/hotplug.d/net/20-ntpclient (restarted, rather than reloaded, ntpclient). According to the file comments the latter "net" action fires on every network event so presumably that fires on getting a WAN ip via 3G in a way that the "iface-up" action didn't.
It's interesting that the clock was previously correctly getting set once the connection came up (but not thereafter); I can only assume that had nothing to do with npclient and was maybe something the PPP session did directly based on a timestamp from the mobile network?
On Wed, Feb 23, 2022 at 01:05:39PM +0000, Mark Rogers wrote:
I think this might be more about my expectation than anything else but I am struggling to get ntpclient to work (on an openwrt-based box).
What device is it and which version of openwrt? By default openwrt devices run ntpd to keep the clock synced, I've never had to change the default configuration as it all "just works".
Adam --
On Wed, 23 Feb 2022 at 19:02, Adam Bower adam@thebowery.co.uk wrote:
What device is it and which version of openwrt? By default openwrt devices run ntpd to keep the clock synced, I've never had to change the default configuration as it all "just works".
It's a Teltonika router (they have a wide range of openwrt kit and their own LUCI-based GUI), bought from Solwise.
When I posted here I was waiting on a response from Teltonika support via Solwise - there'd been a bit of to-and-fro and I was becoming convinced that the problem was me (ie something I didn't understand, eg that a default config would accept a drift greater than seemed reasonable to me and I just hadn't waited long enough for it to reach the threshold for correction).
Then two things happened almost simultaneously. MJR's comment about checking ntpclient was running (there was no ntpclient process) and Teltonika sending me a new firmware version to try, which does now have an ntpclient process running and which does now maintain the clock to within around 200ms (I'm sure I can tweak that if I care, but I don't).
I don't know *why* ntpclient wasn't running on the old firmware but from comments that came with the new firmware I think it might be about connection stability so a guess would be that it was failing to start properly if the network wasn't up quickly, and this is a 4G unit so that can take some time. But that's speculation.
Anyhow, it looks like this is now working - thanks all for your input.
-
Adam Bower -
Mark Rogers -
MJ Ray