Description of problem: The default ntp configuration uses ntp pool servers for ntpd proper, but doesn't include them in the step-tickers file, therefore if they system clock is too far off the real time (by more than a few seconds) ntp takes a really long (infinite?) time to synchronize the time. Version-Release number of selected component (if applicable): ntp-4.2.4p2-3.fc7 How reproducible: always Steps to Reproduce: 1. #yum install ntp (if not already installed) 2. #service start ntp Actual results: ntp starts up, but doesn't step the clock to the correct time first. Then the time is never correct, but the user might think it is since ntpd is happily running. Expected results: The clock is stepped to the correct time before ntp starts by putting 0.fedora.pool.ntp.org (and others) in the step-tickers file.
When no server is specified in step-tickers, ntpd will be started with -g option, so it won't exit if the offset is larger than 1000s. It should always step the clock unless there is a different problem. For faster initialization, please add the iburst keyword to the server specifications. Generally, step-tickers shouldn't be used. It doesn't work well with NetworkManager, can cause annoying delay in boot and it shouldn't be used for pool.ntp.org addresses as ntpdate will query every server resolved from the address.
(In reply to comment #1) > When no server is specified in step-tickers, ntpd will be started with -g > option, so it won't exit if the offset is larger than 1000s. It should always > step the clock unless there is a different problem. For faster initialization, > please add the iburst keyword to the server specifications. How fast should it initialize (without iburst)? I've had my laptop run for *days* with ntpd happily running where my clock was incorrect by several minutes. If it takes days to settle, that might be ok for a server or desktop that is always left on, but for laptops and most desktops (which people turn off on a semi-regular basis) it is too long. > Generally, step-tickers shouldn't be used. It doesn't work well with > NetworkManager, can cause annoying delay in boot and it shouldn't be used for > pool.ntp.org addresses as ntpdate will query every server resolved from the address. I see. If ntpd was able to get the clock back on track (less than 1s error) in a matter of minutes I agree.
It depends on many factors, but usually it's less than half an hour. With good drift file it can be less than 5 minutes. When iburst is used it's about 10 seconds. There is something wrong if it didn't sync after one day. It can be a hw or kernel problem (see bug #242621 or bug #231626 for instance). Are there any ntpd messages in the system log? Please post also "ntpq -pn" output.
(In reply to comment #3) > It depends on many factors, but usually it's less than half an hour. With good > drift file it can be less than 5 minutes. Half an hour would certainly be acceptable. > There is something wrong if it didn't sync after one day. It can be a hw or > kernel problem (see bug #242621 or bug #231626 for instance). Are there any ntpd > messages in the system log? Please post also "ntpq -pn" output. I don't really know how to determine if this is a hw or kernel problem. Since boot I have the following (this is when I have step-tickers in my step-tickers file) in /var/log/messages: Sep 17 10:02:50 tbc ntpd[4493]: ntpd 4.2.4p2 Tue Aug 21 14:07:56 UTC 2007 (1) Sep 17 10:02:50 tbc ntpd[4494]: precision = 2.000 usec Sep 17 10:02:50 tbc ntpd[4494]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Sep 17 10:02:50 tbc ntpd[4494]: Listening on interface #1 wildcard, ::#123 Disabled Sep 17 10:02:50 tbc ntpd[4494]: Listening on interface #2 lo, ::1#123 Enabled Sep 17 10:02:50 tbc ntpd[4494]: Listening on interface #3 wlan0, fe80::21b:77ff:fe18:9d0b#123 Enabled Sep 17 10:02:50 tbc ntpd[4494]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Sep 17 10:02:50 tbc ntpd[4494]: Listening on interface #5 wlan0, 192.168.1.100#123 Enabled Sep 17 10:02:50 tbc ntpd[4494]: kernel time sync status 0040 Sep 17 10:02:50 tbc ntpd[4494]: frequency initialized 133.508 PPM from /var/lib/ntp/drift Sep 17 10:07:07 tbc ntpd[4494]: synchronized to 193.228.143.12, stratum 2 Sep 17 10:07:07 tbc ntpd[4494]: kernel time sync status change 0001 ntpq gives me: [matt@tbc ~]$ ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *193.228.143.12 192.36.143.151 2 u 243 256 377 115.491 -4.653 4.255 +194.88.2.50 82.211.81.145 3 u 96 256 377 80.516 -8.522 1.163 +202.73.37.27 133.100.11.8 2 u 92 256 377 258.511 28.839 21.384
That looks ok. If you remove the step-tickers file it will take more than day to sync?
(In reply to comment #5) > That looks ok. > > If you remove the step-tickers file it will take more than day to sync? I removed the step-tickers and it works properly. However (and perhaps this is for another bug report?), ntpd will not start on it's own. I have to manually restart it after I've logged in (and NetworkManager is connected to the network): [matt@tbc ~]$ chkconfig --list ntpd ntpd 0:off 1:off 2:off 3:on 4:off 5:on 6:off [matt@tbc ~]$ sudo service ntpd status ntpd dead but subsys locked [matt@tbc ~]$ sudo service ntpd restart Shutting down ntpd: [FAILED] Starting ntpd: [ OK ]
Is there a message in the log why ntpd exited? Or can you reproduce it when NetworkManager is stopped?
(In reply to comment #7) > Is there a message in the log why ntpd exited? Or can you reproduce it when > NetworkManager is stopped? There's no message as to why it exited, but it is started before NetworkManager starts, so there are no interfaces other than the wildcards. Below is a grep of /var/log/messages for 'ntp' today (I booted the machine at about 8:52 this morning, and noticed that ntp wasn't running and restarted it at 9:46). I went through the whole log by hand to verify that this grep didn't miss anything important. Sep 18 08:52:50 tbc ntpd[2126]: ntpd 4.2.4p2 Tue Aug 21 14:07:56 UTC 2007 (1) Sep 18 08:52:50 tbc ntpd[2127]: precision = 2.000 usec Sep 18 08:52:50 tbc ntpd[2127]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Sep 18 08:52:50 tbc ntpd[2127]: Listening on interface #1 wildcard, ::#123 Disabled Sep 18 09:46:35 tbc ntpd[3877]: ntpd 4.2.4p2 Tue Aug 21 14:07:56 UTC 2007 (1) Sep 18 09:46:35 tbc ntpd[3878]: precision = 2.000 usec Sep 18 09:46:35 tbc ntpd[3878]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Sep 18 09:46:35 tbc ntpd[3878]: Listening on interface #1 wildcard, ::#123 Disabled Sep 18 09:46:35 tbc ntpd[3878]: Listening on interface #2 lo, ::1#123 Enabled Sep 18 09:46:35 tbc ntpd[3878]: Listening on interface #3 wlan0, fe80::21b:77ff:fe18:9d0b#123 Enabled Sep 18 09:46:35 tbc ntpd[3878]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Sep 18 09:46:35 tbc ntpd[3878]: Listening on interface #5 wlan0, 192.168.1.100#123 Enabled Sep 18 09:46:35 tbc ntpd[3878]: kernel time sync status 0040 Sep 18 09:46:36 tbc ntpd[3878]: frequency initialized 131.990 PPM from /var/lib/ntp/drift Sep 18 09:49:55 tbc ntpd[3878]: synchronized to 132.239.1.6, stratum 1 Sep 18 09:52:27 tbc ntpd[3878]: time reset +152.059311 s Sep 18 09:52:27 tbc ntpd[3878]: kernel time sync status change 0001 Sep 18 10:01:24 tbc ntpd[3878]: synchronized to 132.239.1.6, stratum 1
Looks like the loopback interface is missing when ntpd is started. Is loopback configured in /etc/sysconfig/network-scripts/ifcfg-lo ?
(In reply to comment #9) > Looks like the loopback interface is missing when ntpd is started. Is loopback > configured in /etc/sysconfig/network-scripts/ifcfg-lo ? Yes it is (see below), but network is not enabled since I use NetworkManager, so it is never started. [matt@tbc ~]$ cat /etc/sysconfig/network-scripts/ifcfg-lo DEVICE=lo IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 # If you're having problems with gated making 127.0.0.0/8 a martian, # you can change this to something else (255.255.255.255, for example) BROADCAST=127.255.255.255 ONBOOT=yes NAME=loopback
I'm not sure disabling the network service is a good idea. I think there are more services that need lo configured before starting. In any case, please file a new bug for ntp. It should either fail with a message that lo is missing or it should use lo only when it's available. Closing this bug as NOTABUG for now. If the original problem shows again please reopen.