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

[ Thread Index | Date Index | More Archives ]

I wasn't deliberately trying to use two interrupts, but perhaps something I did along the way introduced that.

I'm OK with not using gpsd if that's what's getting in my way here. The use of gpsd was really just driven by online examples that were doing exactly what I'm trying to do (create a compact, GPS driven NTP server using a BeagleBone Black with an AdaFruit Ultimate GPS breakout board).. Having the ability to check the GPS data using cgps is convenient. That way I don't have to visually inspect the NMEA data coming in on the serial port. However, if gpsd is really what's giving me my problems then I'll ditch it and configure chrony to read the NMEA serial port directly.. I'll just need to consult the documentation to figure out how to properly update chrony.conf for that.

On Tue, Nov 28, 2017 at 8:23 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

On Tue, 28 Nov 2017, Joe Smith wrote:

All of the online resources that I found for building a GPS NTP server indicated to install and use gpsd. I have the UART4
(/dev/ttyS4) mapped via a U-Boot overlay. I believe using gpsd and gpsd-clients allows me to easily verify that I'm getting good
GPS data, 3D Fix, etc.
My PPS signal comes from the AdaFruit Ultimate GPS Breakout board that I have connected to my BeagleBone Black. That board has
Tx/Rx pins and a PPS output.

My /etc/default/gpsd file contains the following. It seems like it should be just using /dev/ttyS4 for the serial NMEA data but
you may very well be right that it's assigning /dev/ttyS4 as a source for pps0 given what I see in the dmesg output. Maybe just
something I have wrong/missing in /etc/default/gpsd

The assignment of the /dev/pps? numbers has nothing to do with chrony or gpsd,
or any other user space program. It is assigned by the kernel depending on
what order the drivers request a device number from the kernel. Ie, it is long
before anything else happens. But I have no idea why you have two devices. You
have one pps signal I thought, and if you have two pps drivers they will fight
each other and make your timing much worse. soetimes one, sometimes the other
will get the interrupt first.

So I ask again, why are you using two interrupts?

Furthermore, chrony has the ability to driectly use the pps signal. It does
not need gpsd. I do not run gpsd, and chrony disciplnes my clock to of the
order of 1 microsecond.

# Default settings for the gpsd init script and the hotplug wrapper.

It does not matter.

# Start the gpsd daemon automatically at boot time

# Use USB hotplugging to add new USB devices automatically to the daemon

# Devices gpsd should collect to at boot time.
                        ^^^^^^^^ I assume that should be "coonnect"

# They need to be read/writeable, either by user gpsd or the group dialout.

# Other options you want to pass to gpsd

On Tue, Nov 28, 2017 at 4:21 AM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
      Not sure why you use gpsd. If you are using the serial port, just doing (or
      setting up a script in /etc/init.d and /etc/rc?.d to do an ldattach 18 /dev/ttyS0 should work to set up /dev/pps0
      and chrony can then use that.

      (Or is your pps attached elsewhere).
      And then put
      refclock PPS /dev/pps0
      into chrony.conf.

      William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
      Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
      UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
      Canada V6T 1Z1 ____|____ and Gravity ______|_

      On Mon, 27 Nov 2017, Joe Smith wrote:

            Thanks for your response. I actually did basically what you suggested prior to my post.

             *  Loaded latest BBB debian image onto the BeagleBone eMMC.
             *  Compiled NF3H-PPS-00A0.dts file into a .dtbo file in /lib/firmware
             *  Updated /boot/uEnv.txt to pull in NF3H-PPS-00A0.dtbo and BB-UART4-00A0.dtbo into U-Boot
             *  Rebooted
             *  apt-get update
             *  apt-get upgrade
             *  apt-get dist-upgrade
             *  apt-get autoremove
             *  apt-get autoclean
             *  apt-get install man-db
             *  apt-get install pps-tools

      That should be installed before you try to recompile chrony. In particular,
      you need the /usr/include/sys/timepps.h for chorny to compile in pps.

      You can also use gpsd to handle the pps, and it will feed the pps times into
      a shared memory.

            At this point I could see I was getting PPS pulses on /dev/pps0 using ppstest

             *  apt-get install gpsd


             *  apt-get install gpsd-clients
             *  systemctl disable gpsd.socket
             *  systemctl stop gpsd..service
             *  Made edits to /etc/default/gpsd and /lib/system/gpsd.service
             *  systemctl daemon-reload
             *  systemctl start gpsd.service
            At this point I was able to verify PPS pulses on /dev/pps0 and valid NMEA data coming in on /dev/ttyS4
            (using cgps)

             *  apt-get install chrony
             *  systemctl stop chrony
             *  In chrony source directory...
                 +   ./configure --prefix=/usr --sysconfdir=/etc/chrony  (this set up chronyd.exe to point to
                 +  make install
            Upon my next reboot I found that chrony didn't start. Complaining about /dev/pps0

      I think gpsd may be grabbing pps0.

            Checked /dev/pps1 and saw that pulses were now coming in there
            Changed chrony.conf to use /dev/pps1
            Saw using systemctl status chrony that the daemon didn't start because it couldn't access /dev/pps1
            Verified I was getting PPS pulses on /dev/pps1 using ppstest
            Started chrony using systemctl start chrony
            Saw using systemctl status chrony that the daemon started successfully
            Examined dmesg output to verify pps1

            I'm not entirely sure what step along the way the PPS switched over to /dev/pps1. All I can tell right
            now is that once that
            happens chrony won't start during boot due to it not being able to access /dev/pps1 at the time systemd
            starts it (or so it
            seems). My plan is to take this BBB back to the base BBB debian image again and do reboots after each
            step (after installing
            pps-tools), checking PPS after each reboot to try an isolate what step seems to cause the switchover. My
            hope is that once I
            isolate that I will be able to figure out what needs to change to get chrony to start successfully on

      TRy not starting gpsd.

            On Mon, Nov 27, 2017 at 6:47 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
                  Firstly, your problem was I believe that chrony as delivered by debian did not
                  support pps. You can make sure that it does by simply installing pps-tools by
                  debian and then recompiling the Debian chrony. Chrony looks for the file
                  /usr/include/sys/timepps.h and if it is theere it compiles with PPS support.
                  So just install pps-tools, and then do whatever you need to on debian to
                  recompile chrony source. (I use Mageia/rpm, and there a simple rpmbuild --rebuild <chrony src rpm>
            would recompile
                  it with pps support. That might well solve the original
                  problem you had.
                  If pps0 is taken by something then the pps support in the kernel would use
                  As you propose a link from /etc/chrony.conf to /etc/chrony/chrony.conf would
                  solve the problem of the location of chrony.conf.
                  Ie, since you are having loats of problems with compiling the latest chrony
                  going with the distribution's chrony is probably the easierst way to get it
                  disciplining your system.

                  William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
                  Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
                  UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
                  Canada V6T 1Z1 ____|____ and Gravity ______|_

                  On Mon, 27 Nov 2017, Joe Smith wrote:

                        Unfortunately chronyd doesn't appear to like that setting. Upon reboot it complained that
            dropping root
                        privileges was not
                        supported. I rebuilt again without it but now appear to be encountering other problems, more
            related to
                        BBB and debian I think.
                        Seems like I can't seem to predict very well what device gets assigned for PPS and why. When
            I started
                        the setup process the PPS
                        was going to /dev/pps0 as I would expect. Then after my last reboot it was getting assigned
                        and it appears that device
                        isn't ready at the time chronyd is started by systemd so it has to be started up manually
                        systemctl which is a no-go for
                        my application. I posted to the BeagleBone google group to see if anyone has ideas as to
            why. I'm
                        relatively sure it has to do
                        with the startup order from systemd but I'm not expert enough to know how to remedy it.
                        I want to thank you again for all of the help you've been providing (and the patience).
            There are sooooo
                        many deep technical
                        details to all of this that it's hard to come up to speed.

                        On Mon, Nov 27, 2017 at 12:04 PM, Joe Smith <joe.smith@xxxxxxxxxxxxxxxxxxx> wrote:
                              It appears that the apt-get chrony package creates a _chrony user and _chrony group
            for the
                        daemon. That is the user
                              that currently owns /var/run/chrony. When I started chrony after building/installing
            from source I
                        did a "sudo
                              systemctl start chrony" and the chronyd.exe process that is running is owned by root. 
            Given this,
                        it looks like the
                              best course of action is probably to rebuild with the --with-user=_chrony option. I'm
                        (possibly wrongly)
                              that the daemon switches the user to _chrony after it starts up if it's built with
            that option.

                        On Mon, Nov 27, 2017 at 11:44 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
                              On Mon, Nov 27, 2017 at 11:15:07AM -0500, Joe Smith wrote:
                              > Seems to be working now although I do get this warning/error from systemctl
                              > status chrony
                              > Wrong owner of /var/run/chrony (UID != 0)
                              > Not sure that it's significant given that it seems to be running properly.

                              That indicates the previous chronyd dropped root privileges (the owner
                              of /var/run/chrony is not root), but the new one is keeping them and
                              refusing to write to the directory. It will not be possible to use
                              chronyc to make changes in the configuration until you reboot or
                              remove the directory and restart chronyd.

                              You should either recompile chrony with the correct user specified by
                              the --with-user option, or specify the user with the -u option on
                              the chronyd command line or use the user directive in chrony.conf.

                              Miroslav Lichvar

                              To unsubscribe email
                              with "unsubscribe" in the subject..
                              For help email
                              with "help" in the subject.
                              Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxg.

Mail converted by MHonArc 2.6.19+