Re: [chrony-users] Fatal error : adjtimex() failed

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Mon, 20 Aug 2012, Tomalak Geret'kal wrote:

> On 20/08/2012 21:58, Bill Unruh wrote:
> >  Sorry cannot say, but there is a manual adjtimex program under linux
> >  ( man 8 adjtimex)
> >  which you could try running and see if you get some error messages.
> >
> >  Also the system call adjtimex sets errno, and you should be able to get
> >  more
> >  info out of it. I cannot remember if chrony actually reports the error but
> >  apparently not.
> >
> >
> > > 
> > >  In the syslog:
> > > 
> > >  Aug 20 17:32:50 sw200319 daemon.info chronyd[2186]: chronyd version 1.26 
> > >  starting
> > >  Aug 20 17:32:50 sw200319 daemon.info chronyd[2186]: Linux kernel major=2 
> > >  minor=6 patch=21
> > >  Aug 20 17:32:50 sw200319 daemon.info chronyd[2186]: hz=100 shift_hz=7 
> > >  freq_scale=0.99902439 nominal_tick=10000 slew_delta_tick=833 
> > >  max_tick_bias=1000
> > >  Aug 20 17:32:50 sw200319 daemon.crit chronyd[2186]: Fatal error : 
> > >  adjtimex() failed
> >
> >  (are you sure you did not truncate this error message-- ah no, in 1.26 all
> >  of
> >  the explanations of why adjtimex failed were removed. Not terribly
> >  helpful.
> >
> >  You could go into sys_linux.c and put in the failure messages again so you
> >  would know why it failed.
> >
> >
> > > 
> > >  I read that adjtimex() can fail when the HZ and SHIFT_HZ values are
> >
> >  No use guessing. find out why it failed.
>
> I did, by modifying the source (see my second post), but then the error 
> changed. I'm finding a completely illogical pattern of when chrony starts 
> properly, when it fails with that shmget error and when it fails with the 
> adjtimex error. My version with the altered log strings (and *nothing* else!) 
> has so far never come up with the adjtimex error so I've not been able to see 
> the errno yet.
>
> And when it *does* start up successfully, I find that after some time (this 
> varies, but on last observation was around ten minutes after startup) my GPS 
> source is being selected over my PPS source (after a "no majority" event), 
> and the PPS source is apparently never selected again.
>
> Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: chronyd version 1.26 
> starting
> Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: Linux kernel major=2 
> minor=6 patch=21
> Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: hz=100 shift_hz=7 
> freq_scale=0.99902439 nominal_tick=10000 slew_delta_tick=833 
> max_tick_bias=1000
> Aug 20 20:35:07 sw200319 daemon.err chronyd[2098]: Could not open IPv6 NTP 
> socket : Address family not supported by protocol
> Aug 20 20:35:07 sw200319 daemon.err chronyd[2098]: Could not open IPv6 
> command socket : Address family not supported by protocol
> Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: Frequency -32.801 +- 
> 0.047 ppm read from /etc/chrony.drift
> Aug 20 20:37:00 sw200319 daemon.info chronyd[2098]: Selected source GPS
> Aug 20 20:37:34 sw200319 daemon.info chronyd[2098]: Selected source PPS0
> [..]
> Aug 20 20:44:19 sw200319 daemon.info chronyd[2098]: Can't synchronise: no 
> majority
> Aug 20 20:45:56 sw200319 daemon.info chronyd[2098]: Selected source GPS

Hmm. How are you feeding the shm? The PPS source cannot give you the seconds.
It is only accurate to the nsec, but completely oblivious to seconds, so you
have to do something to feed it the seconds. That could be the gps itself, or
some other source.


> [sw200319 /root]# chronyc sources
> 210 Number of sources = 2
> MS Name/IP address           Stratum Poll LastRx Last sample
> ============================================================================
> #? PPS0                          0    4    43m  -1607ms[ +400ms] +/-  155ms
> #* GPS                           0    4     16    -14ms[  -14ms] +/-   60ms

That indicates that the PPS is almost 2 seconds out from the gps. a few 10s or
even 100s of ms I could understand, but this indicates that the pps source is
getting the wrong seconds information.

Also a fluctuation of 400ms or even 155 ms is pretty huge.


> [sw200319 /root]# cat /etc/chrony.conf
> allow
> refclock PPS /dev/pps0 lock GPS

Hmm. that should lock to the gps signal,

> refclock SHM 0 offset 0.5 delay 0.1 refid GPS

Try putting in a "noselect" in that line, since you do not want the system to
use the GPS time except to give the seconds to PPS.


> keyfile /etc/chrony.keys
> commandkey 1
> driftfile /etc/chrony.drift
>
> There's obviously something very wrong with how I'm trying to use chrony. 
> I'll have to just keep observing and trying to find a pattern in all these 
> odd behaviours that are occurring to me. :(
>
> Tom

--
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/

--
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.