I have NTP configured using us.pool.ntp.org, north-america.pool.ntp.org and pool.ntp.org.

When I look at the syslog I see the following:

 

Apr 18 17:17:08 MEDIASERVER ntpd[1225]: ntpd [email protected] Mon May 7 05:15:03 UTC 2007 (1)
Apr 18 17:17:08 MEDIASERVER ntpd[1226]: precision = 1.000 usec
Apr 18 17:17:08 MEDIASERVER ntpd[1226]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16

Apr 18 17:17:10 MEDIASERVER ntpd_initres[1233]: host name not found: us.pool.ntp.org
Apr 18 17:17:10 MEDIASERVER ntpd_initres[1233]: couldn't resolve `us.pool.ntp.org', giving up on it
Apr 18 17:17:10 MEDIASERVER ntpd_initres[1233]: host name not found: north-america.pool.ntp.org
Apr 18 17:17:10 MEDIASERVER ntpd_initres[1233]: couldn't resolve `north-america.pool.ntp.org', giving up on it
Apr 18 17:17:10 MEDIASERVER ntpd_initres[1233]: host name not found: pool.ntp.org
Apr 18 17:17:10 MEDIASERVER ntpd_initres[1233]: couldn't resolve `pool.ntp.org', giving up on it

 

I searched for NTP issues and tried to follow the posts, but can't find anything conclusive. My server is configured with a static IP and I'm running version 4.5-beta4.

 

Thanks,

Adrian

Under Network settings, do you have a DNS server IP address defined?  Typically this is the IP address of your router.

Yes all network settings are configured.

 

IP Address: 10.10.10.50

Netmask: 255.255.255.0

Gateway: 10.10.10.1

DNS Server: 10.10.10.1

 

I know my router can resolve pool.ntp.org because I have another server configured using Tardis and it's able to resolve them fine. It's configurations are the same for Gateway and DNS server.

 

Looking at some of the past posts, I saw that there apparently was an issue when a static IP was used , so I'm not sure if that has been fixed or not.

 

Thanks,

Adrian

I'm using static IP and it works fine.

 

Try:

 

0.pool.ntp.org

 

Also can you ping it from your unRAID box?

I've tried, us, north-america, 1, 2, 3, etc...it always shows an error in syslog.

 

As for pinging it, yes it's able to resolve and ping.

 

If I disable NTP then enable it causing it to restart NTP at that point it works fine. So there just seems to be something during startup where NTP is possibly starting too early, like before the network settings are being set.

 

 

This is after restarting NTP when unraid is already up.

 

Apr 18 19:43:02 MEDIASERVER ntpd[8376]: ntpd [email protected] Mon May  7 05:15:03 UTC 2007 (1)
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: precision = 1.000 usec
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: Listening on interface #2 eth0, 10.10.10.50#123 Enabled
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: kernel time sync status 0040
Apr 18 19:43:02 MEDIASERVER ntpd[8377]: frequency initialized 0.000 PPM from /etc/ntp/drift
Apr 18 19:43:20 MEDIASERVER ntpd[8377]: synchronized to 72.18.205.157, stratum 2
Apr 18 19:43:20 MEDIASERVER ntpd[8377]: time reset +8.811854 s

 

I noticed that in the part of the syslog where NTP shows the errors, it never shows the log line

Apr 18 19:43:02 MEDIASERVER ntpd[8377]: Listening on interface #2 eth0, 10.10.10.50#123 Enabled

like it does when I restarted it. So it definitely looks like when NTP is started from a reboot/shutdown its starting before interface #2 (the actual NIC with the static IP) is ready.

Exact same issue as discussed here: http://lime-technology.com/forum/index.php?topic=3633.msg31581#msg31581

 

Even though the network is started first, it is not ready for use when the NTP process goes to use it.

 

NTP daemon needs to be started after a slight delay.  (Also, the suggestion to save the /etc/ntp/drift file to the flash, and restore it prior to restart is a great one to improve the overall accuracy)

 

Joe L

Yup, it's definitely the same issue. So, what it boils down to is that NTP is being started to soon.

4.5-beta5 has updated ntp package, from 4.2.4p0 to 4.2.4p6.  In looking at change log between the two versions it appears this issue has been addressed.