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

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





On Wed, 29 Nov 2017, Joe Smith wrote:

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

Yes. Lichvar seems to feel that it was gpsd that was doing that. Somewhere
perhaps you have a configureation for gpsd which tells it to use /dev/ttyS4.

I do not know how to use chrony to directly read the nmea. I only use the PPS
on ttyS1, and launch pps-ldisc 18 /dev/ttyS1 from a script which systemd runs
on bootup. I use network ntp to get the seconds for chrony and pps, not nmea.




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

Is it a serial port or is it a usb input?


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.

Sorry I cannot help there.


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
            START_DAEMON="true"

            # Use USB hotplugging to add new USB devices automatically to the
            daemon
            USBAUTO="false"

            # 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.
            DEVICES="/dev/ttyS4"

            # Other options you want to pass to gpsd
            GPSD_OPTIONS="-n"

            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 ______|_
            www.theory.physics.ubc.ca/

                  On Mon, 27 Nov 2017, Joe Smith wrote:

                        Bill,
                        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
                        configuration
                         *  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


                  Why?


                         *  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
                        /etc/chrony/chrony.conf)
                             +  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
                        Rebooted
                        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
                        reboot/power-cycle.



                  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
                              pps1.
                              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 ______|_
            www.theory.physics.ubc.ca/

                              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
                        /dev/pps1
                                    and it appears that device
                                    isn't ready at the time chronyd is started by
            systemd so it has to be started up manually
                        using
                                    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
                        assuming
                                    (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
            chrony-users-request@xxxxxxxxxxxxxxxxxxxx
                                          with "unsubscribe" in the subject.
                                          For help email
            chrony-users-request@xxxxxxxxxxxxxxxxxxxx
                                          with "help" in the subject.
                                          Trouble?  Email
            listmaster@xxxxxxxxxxxxxxxxxxxx.












Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/