NTPsec panic and abort

[Hal Murray]

Interesting.  Thanks.

That exit is what happens if you try to adjust the time by too large a step.  
It's just a sanity check -- assuming that exiting ntpd is better than making a 
large adjustment.

I forget what the default max-step is.  You can change it via the config file. 
 You can bypass that check for the first adjustment with a -g on the command 
line.

>> Mar 18 05:10:10 gw1 ntpd[2200]: CLOCK: Panic: offset too big: -604800.000
What time zone is your logging using?

>> 59655 86030.616 NMEA(0) $GPRMC,235350,A,____.____,_,_____.____,_,000.0,31=
5.7,170322,001.5,W*__

> Note the spurious "100322" date that is 1 week in the past.

I don't see a "100322".  I see 17 rather than 10.

I'm assuming you copied the wrong chunk from the clockstats file.


> I have never come across such an ntpd abort before. This is the first time
> I'm seeing it.
Mostly, GPS units don't lie.

> Can this condition be handled in any other way, so that the service doesn't
> terminate?

How should ntpd decide if the GPS is lying or the time really is off by a week?


Do you have any other servers in your config file?

If there are several working servers, they should out-vote a lying GPS.
But the GPS has a prefer so I'm not sure what would happen.

You are using the PPS in the NMEA driver.  I don't think that needs the prefer.

I usually run with a separate PPS driver so I get the statistics from the PPS 
driver.  That case does need the prefer.


-- 
These are my opinions.  I hate spam.