On Thursday, 24 August 2017 12:51:38 BST Ralph Corderoy wrote: > Where was this script? I forgotten upstart, but it probably still copes > with scripts in /etc/init.d. If it's one of those, see update-rc.d(8). > https://debian-handbook.info/browse/stable/unix-services.html#sect.system-bo > ot
The script that I modified was the standard one to start ntpd. It is installed in /etc/init.d. Anyway, I've moved on a bit since then (see below). > I notice date(1) says UTC on one machine, and GMT on the other. The I hadn't spotted that. I'll make them the same. > `-q' could do with a `-g' if you expect the discrepancy to be large. > The `KoD... inconsistent xmt/org/rec timestamps. Ignoring.' that last > some minutes are because the incoming packets from the server don't have > those three timestamps set to the xmt one that was sent out. I don't > know why that would be. Yes. I kind of worked out what the error was, but not necessarily the cause. > > As you can see, the sync is quicker, but it still took nearly 5 > > minutes. I'm not sure why the daemon takes that long, but it may be > > as good as it gets. Does anyone know? > > Not getting those `ignoring' messages will probably shorten that. Wouldn't that be nice :-) > > Final question; I can only start ntpd as root, so I intend to put the > > startup line in the /etc/ rc.local. > > If it's installed as a package then it will have a start-up script to > enable, as pointed to above. Look at the contents of the package with > `dpkg -l $packagename'. I think that your ntp-wait (see below) is a better approach anyway. > > I now understand a little more about the Kiss of Death packet that is > > being sent by the server. I have discovered that the server is > > comparing timestamps from the RTC and the system files and suppressing > > the transmission of a valid signal until they are consistent, but why > > they shouldn't be I'm not sure. > > Was https://afterthoughtsoftware.com/products/rasclock closely followed > on installation? Look at dmesg(1) output after booting and see if it > mentions clocks or time sources. Could the `fake-hwclock' they ship in > Raspbian be interfering? I revisited the config instructions at that link and discovered that I'd missed out a step ;-( That's the penalty of having the instructions on one screen and the file being edited on another in a room at other end of the house! I've fixed that now, but I need to leave time for the RTC to get it wrong again, in case there is still some error somewhere. > > Bad news this morning I'm afraid. I turned on the system to confirm > > yesterday's results and ran 'sudo ntpd -q' immediately after buttspi > > had booted, exactly as I did yesterday. The daemon reported its > > progress, exactly as before, but it exited without syncing. I tried a > > few more times with the same results. > > That could be the lack of -g mentioned above. I tried this several more times and then went back to the default method of launching ntpd. After approx 10 minutes the clocks synced. I'll investigate the discrepancy between the timezones on the two devices and see if that helps. > ntp-wait(1) might be of interest: "This can be useful at boot time, to > delay the boot sequence until after ntpd -g has set the time". That is definitely of interest. If all else fails, then this could ensure that the clocks are synced before we try to run our software. However, the man page isn't very helpful with respect to when to launch it and where from. Since there isn't much point in delaying the start of the system until NTP itself has started, then I'm assuming that I could put it into rc.local, except that this file has the following comment in it: # This script is executed at the end of each multiuser runlevel. If it waits until the end of the runlevel, is that too late? Presumably, as long as further processing is delayed before we launch our software from .bashrc, we should be OK. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
