# ntpdate does not set system time



## marcinkk (Nov 13, 2014)

After the command `ntpdate europe.pool.ntp.org` I can see:

```
13 Nov 11:04:46 ntpdate[72256]: step time server 5.9.29.107 offset -737.509519 sec
```

But after that:

```
# date
Thu Nov 13 11:17:29 CET 2014
```

Time was not set 

I know, that I can set time manually, but I have set ntpd and in /var/log/messages I can read (some chosen lines only):

```
Oct 24 13:31:23 misiak ntpd[13892]: time reset -8.653670 s
Oct 25 09:40:17 misiak ntpd[13892]: time reset -58.858895 s
Oct 26 21:08:25 misiak ntpd[13892]: time reset -161.804938 s
Nov  1 04:17:12 misiak ntpd[13892]: time reset -303.856280 s
Nov  3 23:28:54 misiak ntpd[13892]: time reset -373.967102 s
Nov  9 11:22:22 misiak ntpd[13892]: time reset -589.768542 s
```

So the time difference grows and the system clock is not set.


----------



## Uniballer (Nov 13, 2014)

What version of FreeBSD are you running?  On what platform?  What hardware do you have?  Are you already running ntpd when you run ntpdate?


----------



## wblock@ (Nov 13, 2014)

Is this a VM?  How far off is the time immediately after running ntpdate(8)?


----------



## phoenix (Nov 13, 2014)

I've found that if you are running ntpd, you can't run `ntpdate` to set the clock (ntpd locks the clock somehow). Stop ntpd, run `ntpdate`, then restart ntpd.

Or use OpenNTPd with the -s option, which does the equivalent of ntpdate at startup.


----------



## kpa (Nov 13, 2014)

phoenix said:


> I've found that if you are running ntpd, you can't run `ntpdate` to set the clock (ntpd locks the clock somehow). Stop ntpd, run `ntpdate`, then restart ntpd.
> 
> Or use OpenNTPd with the -s option, which does the equivalent of ntpdate at startup.



Most likely ntpd(8) hogs UDP port 123 and ntpdate(8) can not bind to the same port for sending its own queries. Yes, NTP is a brain dead protocol


----------



## marcinkk (Nov 13, 2014)

FreeBSD 8.4 x86.

Is it possible that one application locks somehow system time change? How? I had run the oscam application. I've stopped it, than I've run `ntpdate` and the time was set.


----------



## tingo (Mar 22, 2016)

FWIW, I see the same thing with later revisions of oscam. nptd will work nicely for a while (a week or two), then it looses sync and gives up, resulting in a line like this in /var/log/messages:

```
Mar 16 14:32:55 kg-v2 ntpd[80115]: time correction of -1200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
```
sometimes it is even more out of whack:

```
Mar 20 12:55:36 kg-v2 ntpd[14671]: time correction of -2400 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
```
each time, I must stop oscam, use ntpdate to get the clock synced up again, start ntpd before finally starting oscam again.
If I get ntp before it gets out of sync, everything is ok:

```
root@kg-v2# ntpq -p
  remote  refid  st t when poll reach  delay  offset  jitter
==============================================================================
*kg-omni1.kg4.no 81.175.5.182  2 u  942 1024  377  0.181  0.045  0.062
```
I'm running FreeBSD 8.4-stable

```
root@kg-v2# uname -a
FreeBSD kg-v2.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #8 r288306: Sun Sep 27 13:35:38 CEST 2015
  root@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
```
Note: I'm running a self-compiled version of oscam, not the port. Currently running revision 11211:

```
root@kg-v2# pgrep -lf oscam 
76561 ./2016/oscam-svn/Distribution/oscam-1.20-unstable_svn11211-amd64-undermydesk-freebsd-libusb-pcsc -c /home/tingo/work/dvb
76560 ./2016/oscam-svn/Distribution/oscam-1.20-unstable_svn11211-amd64-undermydesk-freebsd-libusb-pcsc -c /home/tingo/work/dvb
```
I have also seen this problem when running revision 10679.
Before that I was running revision 9602, and I can't remember having ntp getting out of sync there.


----------



## pkubaj (Mar 22, 2016)

tingo said:


> FWIW, I see the same thing with later revisions of oscam. nptd will work nicely for a while (a week or two), then it looses sync and gives up, resulting in a line like this in /var/log/messages:
> 
> ```
> Mar 16 14:32:55 kg-v2 ntpd[80115]: time correction of -1200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
> ...


8-STABLE is already unsupported. Upgrade to at least 9-STABLE (or better 10-STABLE since 9-STABLE is supported till the end of year).


----------



## tingo (Mar 22, 2016)

pkubaj said:


> 8-STABLE is already unsupported. Upgrade to at least 9-STABLE (or better 10-STABLE since 9-STABLE is supported till the end of year).


I know  It doesn't affect this problem anyway - the problem exists whatever version of FreeBSD you run.


----------

