Time sync on boot using NTP, won't work

[khinch]

I am running a desktop with SLED10 and would like it to automatically synchronise the clock on each bootup. If I open YaST > Network services > NTP Client and select a server from the list (for example ntp2b.mcc.ac.uk) and click "test" it updates the clock. Perfect.

However, if I select "during boot" on the same screen, it clearly does not sync the time on boot. Furthermore, if I go back into the NTP Client screen in YaST, it has forgotten my previous settings. I have tried editing /etc/ntp.conf, and adding the line "server ntp2b.mcc.ac.uk", which keeps my chosen server as the default in the NTP Client screen, but it's still not synchronising on boot.

I noticed something about an attempt to sync time during bootup followed by "failed", so I checked /var/log/boot.msg and found this:

Try to get initial date and time via NTP from ntp2b.mcc.ac.ukError : Temporary failure in name resolution
failed
Try to set the CMOS clockdone
Starting network time protocol daemon (NTPD)<notice>startproc: execve (/usr/sbin/ntpd) [ /usr/sbin/ntpd -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp -i /var/lib/ntp ],

So it looks like it is trying at least. Shouldn't the NTPD be started before NTP tries to sync the clock? Any suggestions appreciated.

[sdousley]

the NTPD will be a ntp server, so wether it's started before or after shouldn't matter. What is more likely to be the cause is if you use DHCP. It may be that the DHCP requests an IP address, then before it gets the IP address, NTP requests the time. Because it doesn't have an IP when NTP requests the time, the name resolution fails as it cant query a DNS server as it has not IP address.

I recall having this issue myself back when i used SuSE. If possible, maybe try setting the computer to use Static IP addressing (at least temporarily, if you do use DHCP) to confirm this. If it's the case, you could try and find a way of making NTP load later in the boot process. Giving it a better chance to gain an IP address from the DHCP server and therefore allow it to run through no problems.

[khinch]

the NTPD will be a ntp server, so wether it's started before or after shouldn't matter.

So unless I'd like to supply time to the rest of the network (which I don't) this daemon is unnecessary and just wasting processor cycles? Should I switch it off?

What is more likely to be the cause is if you use DHCP.

Coincidently I recently stopped using DHCP for another reason, now I use static IPs. I have a HP Photosmart 3210 all-in-one which I use across the network, and it causes problems if it's IP changes (even though the drivers are supposed to detect it anyway).

After checking /var/log/boot.msg it is setting up the network IP etc long before the time tries to sync.

you could try and find a way of making NTP load later in the boot process.

Under /etc/init.d/rc3.d ntp is numer 10 (S10ntp). I believe by increasing this number it will start later in the boot process?

Strangely, this morning it worked anyway, which is almost annoying since I haven't changed anything. If I had changed something, at least I would know maybe what fixed it, and since I haven't changed anything, it leads me to believe it might break again just as easily.

[khinch]

Ok, I finally got this sorted, although I'm not 100% sure exactly what fixed it. I changed the name of the file in /etc/init.d/rc3.d/ from S10ntp to S13ntp, and in YaST > Network Devices > Network Card I selected "traditional mode with ifup" instead of "user controlled network manager", and I am using a static IP address specified in the network card settings.

[khinch]

Update:

Recently I have re-installed my desktop and had no problems with NTP at all. It seems that making the NTP server load later in the boot process was unnecessary.

I configured the network settings for a static IP using "traditional mode with ifup".
Then started NTP on bootup using YaST.
Next I added "server ntp2b.mcc.ac.uk" to the /etc/ntp.conf file.
Finally I used YaST sysconfig editor to make NTP write to the CMOS clock.

Job done.