Re: [chrony-users] Configuring chrony debian service - BBB

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


Oops. Didn't see your other response. Yes, that "After" directive is mainly what did the trick. I also removed "After=chronyd.service" from gpsd.service as it seemed to be causing problems with gpsd startup.

Thanks for the links! I'll take a look at those to see if that's a better way to have this work the way I want.

On Thu, Nov 30, 2017 at 6:52 AM, Joe Smith <joe.smith@xxxxxxxxxxxxxxxxxxx> wrote:
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/