Bug 293271 - default ntp configuration doesn't have step-tickers
default ntp configuration doesn't have step-tickers
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
7
All Linux
medium Severity low
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-17 10:11 EDT by Matthew Truch
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-19 04:07:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Truch 2007-09-17 10:11:35 EDT
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.
Comment 1 Miroslav Lichvar 2007-09-17 10:41:45 EDT
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.
Comment 2 Matthew Truch 2007-09-17 10:53:11 EDT
(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.  
Comment 3 Miroslav Lichvar 2007-09-17 11:37:00 EDT
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.
Comment 4 Matthew Truch 2007-09-17 11:54:43 EDT
(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@1.1495-o 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

Comment 5 Miroslav Lichvar 2007-09-17 12:21:07 EDT
That looks ok.

If you remove the step-tickers file it will take more than day to sync?
Comment 6 Matthew Truch 2007-09-18 10:45:17 EDT
(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  ]
Comment 7 Miroslav Lichvar 2007-09-18 11:10:56 EDT
Is there a message in the log why ntpd exited? Or can you reproduce it when
NetworkManager is stopped?
Comment 8 Matthew Truch 2007-09-18 11:20:56 EDT
(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@1.1495-o 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@1.1495-o 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
Comment 9 Miroslav Lichvar 2007-09-18 12:42:08 EDT
Looks like the loopback interface is missing when ntpd is started. Is loopback
configured in /etc/sysconfig/network-scripts/ifcfg-lo ?
Comment 10 Matthew Truch 2007-09-18 13:14:52 EDT
(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
Comment 11 Miroslav Lichvar 2007-09-19 04:07:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.