Re: [chrony-users] Configuring chrony debian service - BBB |
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]
Got rid of commandkey. I had planned to do that for a while but hadn't because it didn't seem to be causing any serious problem.That was precisely it. /dev/pps0 wasn't getting created by the kernel until later in the bootup process. I had to make some changes to chronyd.service and gpsd.service to ensure that both come up properly on boot. Main thing was to delay chronyd startup.I had to make a change to the chrony.conf to add makestep. For reasons I'm not yet sure of, the system clock on this BeagleBone always comes up waaaaaay off (like 26 days) at boot time. It would take an eternity for chronyd to get in sync with that big of a delta. The only purpose in life for this little server is to provide NTP so I'm not worried about any other applications being sensitive to the clock step. Just seems like the kernel would persist the system clock periodically so that when it boots up it's at least in the ballpark. I thought I read that it does that somewhere but can't remember where. I'll need to go back and research that. I may end up having to add some sort of battery backed RTC to this design to address it.On Wed, Nov 29, 2017 at 10:19 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
GEt rid of the commandkey line in chrony.conf
Nov 03 17:16:53 beaglebone chronyd[590]: commandkey directive is no longer
supported
Nov 03 17:16:53 beaglebone chronyd[572]: open() failed on /dev/pps0
Does /dev/pps0 exist when chrony starts? Chrony will not load the pps-ldisc
module itself. You have to make sure it is loaded before chrony starts
I do it by putting a script into /etc/init.d with the appropriate pointer in
the /etc/rc.d/rc?.d directories. (NOt sure what the Debian numbering is of
the rc?.d )
--------------------------
#! /bin/sh
#
# gps Support for NTP i gps clock. #
# chkconfig: 345 70 15
# description: gps is a module to read the PPS
# Get config.
.. /etc/sysconfig/network
# Get functions
.. /etc/rc.d/init.d/functions
module="gps"
device="gps"
mode="664"
group=wheel
case "$1" in
start)
gprintf "Starting gps pps service"
modprobe pps-ldisc
ldattach 18 /dev/ttyS0
;;
stop)
killall ldattach
echo
;;
status)
status ldattach
;;
restart)
$0 stop
$0 start
;;
*)
gprintf "Usage: gps {start|stop|status|restart}\n "
exit 1
esac
--------------------------------------------
Nov 03 17:16:53 beaglebone systemd[1]: chrony.service: Control process exited,
code=exited status=1
Nov 03 17:16:53 beaglebone systemd[1]: Failed to start chrony, an NTP
client/server.
Nov 03 17:16:53 beaglebone systemd[1]: chrony.service: Unit entered failed state.
Nov 03 17:16:53 beaglebone systemd[1]: chrony.service: Failed with result
'exit-code'.
I verified PPS with ppstest
debian@beaglebone:~$ sudo ppstest /dev/pps0
So it looks like /dev/pps0 was eventually started. It is a timing problem --
pps0 needs to be created before chrony starts
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1478194022.222516784, sequence: 573 - clear 0.000000000,
sequence: 0
source 0 - assert 1478194023.305849881, sequence: 574 - clear 0.000000000,
sequence: 0
source 0 - assert 1478194024.389182301, sequence: 575 - clear 0.000000000,
sequence: 0
If I then start chronyd manually using "sudo systemctl start chrony" it starts
successfully and I can see both sources
debian@beaglebone:~$ chronyc sources
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
============================================================ ===================
#? NMEA 0 4 377 11 +3819us[+3819us] +/- 106ms
#* PPS 0 4 377 12 +417ns[ +732ns] +/- 1042ns
Only reason I can think of is that /dev/pps0 isn't there yet at the time systemd
starts chronyd. Thoughts?
Yup, that is what I think.
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |