Description of problem: On a laptop thats only ever connected via WiFi (GnomeNetworkManager), 'ntpd' never synchronises with the NTP servers. [root@achiles ~]# ntpstat unsynchronised time server re-starting polling server every 64 s However, on connecting via cable, 'ntpd' correctly synchronises with the NTP servers. Version-Release number of selected component (if applicable): latest updated FC5 as of 12-Sept-2006. How reproducible: Always Steps to Reproduce: 1. Configure your laptop to connect via WiFi using the GnomeNetworkManager program. 2. Shutdown/restart and run ntpstat as normal user or root Actual results: ntp is always unsynchronized Expected results: ntp should show synchronized state as it does when connected directly to the internet via ethernet cable. Additional info:
After repeatedly running 'ntpstat' as root for about 10 minutes, it finally shows: [root@achiles ~]# ntpstat synchronised to NTP server (192.245.169.15) at stratum 2 time correct to within 11 ms polling server every 64 s Why does it not synchronise automatically, immediately after WiFi connection is established?
Can you post the output from "/usr/sbin/ntpq -pn" corresponding to the ntpstat unsynchronised and synchronised state?
In the unsynchronized state: [root@achiles ~]# /usr/sbin/ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 LOCAL(0) 10 l 51 64 7 0.000 0.000 0.002 [root@achiles ~]# ntpstat unsynchronised time server re-starting polling server every 64 s [root@achiles ~]#
In the synchronized state: [root@achiles ~]# ntpstat synchronised to local net at stratum 11 time correct to within 449 ms polling server every 64 s [root@achiles ~]# /usr/sbin/ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.1.0 LOCAL(0) 10 l 35 64 37 0.000 0.000 0.002 [root@achiles ~]#
The ntpq output doesn't show any ntp server. Looks like the network interface was enabled after ntpd has started. Unfortunately ntpd version that is in FC5 can't handle this situation. Upstream has fixed it in development version, will be in ntp-4.2.4. The workaround is to not use NetworkManager or restart the ntp service manually when the interface is ready.
That does indeed seem to be the problem - there are many other little things that do not work with NetworkManager/WiFi without manual intervention. The Gnome Weather applet is one such little thing. Anyway, my problem was a little to do with the fact that ntpd doesn't seem to handle a late network start (a-la NetworkManager/WiFi) and the fact that the hardware clock keeps drifting because of 191458 - which I hear is fixed in FC6 as well.
This seems to be happening on a desktop connected to a wired LAN!!!! See attached screenshot - my desktop is almost 7 minutes off!!!!
Created attachment 145979 [details] NTP not working This is a screenshot on a Dell desktop with a dual core Intel processor, 1GB RAM and a WIRED connection to the internet.
Can you post the output from "/usr/sbin/ntpq -pn" command?
I can't believe this is not working!! It works on my second Windows(!?!?!?!) desktop and it doesn't on FC6 - I've updated it this morning. How can this million-year-old utility work on Windows and not work on GNU/Linux?!?!?!?! [root@ ~]# ntpstat synchronised to local net at stratum 11 time correct to within 11 ms polling server every 1024 s [root@ ~]# [root@ ~]# [root@ ~]# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.1.0 .LOCL. 10 l 55 64 377 0.000 0.000 0.001 80.239.2.146 .INIT. 16 - - 1024 0 0.000 0.000 0.000 80.51.167.97 .INIT. 16 - - 1024 0 0.000 0.000 0.000 84.16.227.218 .INIT. 16 - - 1024 0 0.000 0.000 0.000 [root@ ~]#
Ok, it doesn't work because ntpd couldn't reach any of the configured servers. Are you using NetworkManager? If yes, this may be the same problem as with wifi connection, the ntpd daemon is started earlier than the connection.
Yes... but I was under the impression that this was fixed in FC6? Am disabling NetworkManager on my desktop for now. Can't do so on my laptop for obvious reasons. It would be nice if ntpd could be dependent on NetworkManager and therefore, started after NetworkManager.
Well, it should work with ntp-4.2.4-1.fc6. The package is in the updates-testing repository for a few days. If you have already the package installed, please send me output of grep ntpd /var/log/messages*
Ok. I currently have ntp-4.2.2p4-2.fc6 from stable. In any case, it doesn't seem to be related to NetworkManager. I've just restarted my machine with NetworkManager turned off and the time is still 6 minutes off! ====================================================================== [root@ ~]# ntpstat synchronised to local net at stratum 11 time correct to within 448 ms polling server every 64 s [root@ ~]# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 81.210.192.102 .INIT. 16 u - 64 0 0.000 0.000 0.000 66.33.216.11 .INIT. 16 u - 64 0 0.000 0.000 0.000 63.111.165.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 *127.127.1.0 .LOCL. 10 l 35 64 37 0.000 0.000 0.001 Attaching another screenshot with NetworkManager turned off and after a restart of the machine.
Created attachment 145982 [details] With NM turned off after restarting the machine Screenshot with NetworkManager turned off and the machine restarted.
Then it's a network problem. Try pinging the servers and /usr/sbin/ntpdate -q 81.210.192.102
Yes, you're right. [root@ ~]# ntpdate -q 81.210.192.102 server 81.210.192.102, stratum 0, offset 0.000000, delay 0.00000 19 Jan 14:06:06 ntpdate[3487]: no server suitable for synchronization found I'll have to work with my corporate network to resolve this. Sorry for the bother and thanks for the help.
Quick update: I have NetworkManager running again. NetworkManager doesn't seem to be interfering as ntpd seems to remain unsynchronized a significant bit after I'm logged in. Something in the range of 5-8 minutes. Since ntpd synchronizes so late, I'm guessing NetworkManager has nothing to do with its state. The problem (in my case) was of course that ntp traffic was blocked by the corporate firewall. There was however and in-house ntp server that I've configured now and all's well - even with NetworkManager running.
ntp-4.2.4 is in FC6 updates.