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

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

Bill,

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

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

At this point I was able to verify PPS pulses on /dev/pps0 and valid NMEA data coming in on /dev/ttyS4 (using cgps)

Upon my next reboot I found that chrony didn't start. Complaining about /dev/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.


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@xxxxxxxxxxfamily.org
      with "unsubscribe" in the subject.
      For help email chrony-users-request@xxxxxxxxxxfamily.org
      with "help" in the subject.
      Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxg.






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