Fedora 7: a problem with ntp ?

[Andrew Junev]

Dear All,

I have just installed Fedora 7 on a P-III machine. Firewall and
SeLinux are both disabled. But I still can't get ntp running...
I searched the net but couldn't find the right direction...

Here's what I have:
[root@frontend ~]# ntpstat
unsynchronised
  time server re-starting
   polling server every 64 s
[root@frontend ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 218-185-224-8-b 128.250.36.3     2 u   20   64  377  358.766  -907853 2890.12
 218-185-224-9-b 128.250.33.242   2 u   30   64  377  372.321  -907746 2867.96
 212.57.153.17   195.2.64.5       2 u   47   64  377   81.773  -907581 2879.97
[root@frontend ~]# ntptrace 212.57.153.17
212.57.153.17: stratum 2, offset -0.013595, synch distance 0.096890
ntp0.zenon.net: stratum 1, offset 0.003489, synch distance 0.009358, refid 'GPS'
[root@frontend ~]#

ntp.conf exists and was not changed since its creation during install.
I have another machine running Fedora Core 6 and the ntp works there
just fine! On that machine I didn't do anything special, everything
worked right after system installation. I tried to compare the
settings but found no difference...

When I run ntpdate manually, it seem to synchronise just fine with any
of the servers. But ntpd still won't synchronise afterwards.

What can be wrong? Where should I look to?

Thank you very much in advance!

P.S. Without NTP, system clock seem to run too fast on this machine...

-- 
Best regards,
 Andrew

[Andy Green]

Somebody in the thread at some point said:

>  P.S. Without NTP, system clock seem to run too fast on this
> machine... 
ntp has a "sanity check" limit, if the actual clock and the ntp time
differ by more than this (1000s? one thousand somethings IIRC) then it
just gives up.

I also have a dual core AMD box where the clock is going nuts, much
faster than normal, and ntpd is powerless confronted with the temporal
madness.

-Andy

[Rick Stevens]

On Fri, 2007-09-07 at 17:44 +0100, Andy Green wrote:
>  Somebody in the thread at some point said:
>  
>  > P.S. Without NTP, system clock seem to run too fast on this machine...
>  
>  ntp has a "sanity check" limit, if the actual clock and the ntp time
>  differ by more than this (1000s? one thousand somethings IIRC) then it
>  just gives up.
>  
>  I also have a dual core AMD box where the clock is going nuts, much
>  faster than normal, and ntpd is powerless confronted with the temporal
>  madness. 
Make sure you have the IP addresses of your NTP servers in BOTH the
/etc/ntp/ntpservers and /etc/ntp/step-tickers files.  The first thing
the startup script does is try to run "ntpdate" using the entries in
the ntpservers file.  That will drag your clock into sync with the
servers by brute force, then ntpd can keep it synced.

----------------------------------------------------------------------
- Rick Stevens, Principal Engineer             rstevens(a)internap.com -
- CDN Systems, Internap, Inc.                http://www.internap.com -
-                                                                    -
-         It is better to have loved and lost.  Cheaper, too!        -
----------------------------------------------------------------------

[Andrew Junev]

Friday, September 7, 2007, 9:16:08 PM, you wrote:

>  On Fri, 2007-09-07 at 17:44 +0100, Andy Green wrote:
> > ntp has a "sanity check" limit, if the actual clock and the ntp time
> > differ by more than this (1000s? one thousand somethings IIRC) then it
> > just gives up. 
Ok, I stopped ntpd, ran ntpdate manually and it synced the clocks.
Then I started ntpd again and it still couldn't get synced. So it's
not a 'sanity check' who is not letting the ntpd work.

>  Make sure you have the IP addresses of your NTP servers in BOTH the
>  /etc/ntp/ntpservers and /etc/ntp/step-tickers files.  The first thing
>  the startup script does is try to run "ntpdate" using the entries in
>  the ntpservers file.  That will drag your clock into sync with the
>  servers by brute force, then ntpd can keep it synced. 
Ok, I checked the /etc/ntp/ntpservers and they are the same on both
Fedora Core 6 and Fedora 7 machines containing just 2 lines:
clock.redhat.com
clock2.redhat.com

/etc/ntp/step-tickers are empty on both machines. I have put the same
lines there from 'ntpservers' file but it didn't help.

Oh! I forgot to mention one thing. ntpdate by itself doesn't
work without any parameters given. I have to manually point it to an
ntp server - only then the time gets synced:
[root@frontend ~]# ntpdate
 7 Sep 21:46:04 ntpdate[3909]: no servers can be used, exiting
[root@frontend ~]# ntpdate  213.203.238.82
 7 Sep 21:46:11 ntpdate[3910]: step time server 213.203.238.82 offset -0.872507 sec
[root@frontend ~]#

Maybe this is also important.

Thanks!

[Rick Stevens]

On Fri, 2007-09-07 at 21:51 +0400, Andrew Junev wrote:
>  Friday, September 7, 2007, 9:16:08 PM, you wrote:
>  
>  > On Fri, 2007-09-07 at 17:44 +0100, Andy Green wrote:
>  >> ntp has a "sanity check" limit, if the actual clock and the ntp time
>  >> differ by more than this (1000s? one thousand somethings IIRC) then it
>  >> just gives up.
>  
>  Ok, I stopped ntpd, ran ntpdate manually and it synced the clocks.
>  Then I started ntpd again and it still couldn't get synced. So it's
>  not a 'sanity check' who is not letting the ntpd work.
>  
>  > Make sure you have the IP addresses of your NTP servers in BOTH the
>  > /etc/ntp/ntpservers and /etc/ntp/step-tickers files.  The first thing
>  > the startup script does is try to run "ntpdate" using the entries in
>  > the ntpservers file.  That will drag your clock into sync with the
>  > servers by brute force, then ntpd can keep it synced.
>  
>  Ok, I checked the /etc/ntp/ntpservers and they are the same on both
>  Fedora Core 6 and Fedora 7 machines containing just 2 lines:
>  clock.redhat.com
>  clock2.redhat.com
>  
>  /etc/ntp/step-tickers are empty on both machines. I have put the same
>  lines there from 'ntpservers' file but it didn't help. 
Did you do a "service ntpd restart"?

>  Oh! I forgot to mention one thing. ntpdate by itself doesn't
>  work without any parameters given. I have to manually point it to an
>  ntp server - only then the time gets synced:
>  [root@frontend ~]# ntpdate
>   7 Sep 21:46:04 ntpdate[3909]: no servers can be used, exiting
>  [root@frontend ~]# ntpdate  213.203.238.82
>   7 Sep 21:46:11 ntpdate[3910]: step time server 213.203.238.82 offset -0.872507 sec
>  [root@frontend ~]#
>  
>  Maybe this is also important. 
Yes, ntpdate requires you to pass it a clock server.  I made a minor
boo-boo in saying the /etc/rc.d/init.d/ntpd script uses the clock
sources from ntpservers...it uses step-tickers.  If you see the startup
message "Synchronizing with time server:", then it's trying the ntpdate
command.  If it comes up with "[OK]", then it succeeded and the ntpd
daemon SHOULD be able to keep you in sync (unless your clock is REALLY
fast...in which case you have other problems).

The actual ntpd daemon startup is indicated by the startup message
"Starting ntpd".

Just for your info, here are my files:

[root@golem3 ~]# cat /etc/ntp/ntpservers
clock.redhat.com
clock2.redhat.com
[root@golem3 ~]# cat /etc/ntp/step-tickers
clock.redhat.com
clock2.redhat.com

Works fine for me.  You do have port 123 open on your firewall, right?

----------------------------------------------------------------------
- Rick Stevens, Principal Engineer             rstevens(a)internap.com -
- CDN Systems, Internap, Inc.                http://www.internap.com -
-                                                                    -
-         C program run. C program crash. C programmer quit.         -
----------------------------------------------------------------------

[Andrew Junev]

Friday, September 7, 2007, 10:23:49 PM, you wrote:


>  Did you do a "service ntpd restart"? 
Sure!


>  Yes, ntpdate requires you to pass it a clock server.  I made a minor
>  boo-boo in saying the /etc/rc.d/init.d/ntpd script uses the clock
>  sources from ntpservers...it uses step-tickers.  If you see the startup
>  message "Synchronizing with time server:", then it's trying the ntpdate
>  command.  If it comes up with "[OK]", then it succeeded and the ntpd
>  daemon SHOULD be able to keep you in sync (unless your clock is REALLY
>  fast...in which case you have other problems). 
>  The actual ntpd daemon startup is indicated by the startup message
>  "Starting ntpd". 

I get everywhere 'OK', but it still doesn't work...
Here's the log, I was just typing the commands one by one:

[root@frontend ~]# date
Fri Sep  7 23:21:29 MSD 2007
[root@frontend ~]# service ntpd restart
Shutting down ntpd:                                        [  OK  ]
ntpd: Synchronizing with time server:                      [  OK  ]
Starting ntpd:                                             [  OK  ]
[root@frontend ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 andromeda.cs.pu .CDMA.           1 u    6   64    1  187.712  -46.448   0.002
 banana.irc.gr   192.36.134.25    2 u    5   64    1  160.135  -67.667   0.002
 b.pool.ntp.uq.e 130.102.152.7    2 u    4   64    1  550.855    4.548   0.002
[root@frontend ~]# ntpstat
unsynchronised
  time server re-starting
   polling server every 64 s
[root@frontend ~]# date
Fri Sep  7 23:21:59 MSD 2007
[root@frontend ~]#

Here's the corresponding part of /var/log/messages:

Sep  7 23:21:35 frontend ntpd[4088]: ntpd exiting on signal 15
Sep  7 23:21:39 frontend ntpdate[4115]: step time server 66.187.224.4 offset -0.344342
sec
Sep  7 23:21:39 frontend ntpd[4117]: ntpd 4.2.4p2(a)1.1495-o Tue Aug 21 14:07:56 UTC 2007
(1)
Sep  7 23:21:39 frontend ntpd[4118]: precision = 2.000 usec
Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #0 wildcard, 0.0.0.0#123
Disabled
Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #1 wildcard, ::#123 Disabled
Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #2 lo, ::1#123 Enabled
Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #3 eth0,
fe80::230:5ff:fe22:857#123 Enabled
Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #5 eth0, 172.23.0.133#123
Enabled
Sep  7 23:21:39 frontend ntpd[4118]: kernel time sync status 0040
Sep  7 23:21:39 frontend ntpd[4118]: frequency initialized 0.000 PPM from
/var/lib/ntp/drift




>  Just for your info, here are my files: 
>  [root@golem3 ~]# cat /etc/ntp/ntpservers
>  clock.redhat.com
>  clock2.redhat.com
>  [root@golem3 ~]# cat /etc/ntp/step-tickers
>  clock.redhat.com
>  clock2.redhat.com 
>  Works fine for me. 
I have the same now. And it doesn't work. And I see no reason...


>  You do have port 123 open on your firewall, right? 
I have my firewall disabled at all. So all ports are open.
And other PCs on my home LAN are syncing just fine, so it's not a
provider's fault.

Uhhh...

[Rick Stevens]

On Fri, 2007-09-07 at 23:30 +0400, Andrew Junev wrote:
>  Friday, September 7, 2007, 10:23:49 PM, you wrote:
>  
>  
>  > Did you do a "service ntpd restart"?
>  
>  Sure!
>  
>  
>  > Yes, ntpdate requires you to pass it a clock server.  I made a minor
>  > boo-boo in saying the /etc/rc.d/init.d/ntpd script uses the clock
>  > sources from ntpservers...it uses step-tickers.  If you see the startup
>  > message "Synchronizing with time server:", then it's trying the
> ntpdate
>  > command.  If it comes up with "[OK]", then it succeeded and the ntpd
>  > daemon SHOULD be able to keep you in sync (unless your clock is REALLY
>  > fast...in which case you have other problems).
>  
>  > The actual ntpd daemon startup is indicated by the startup message
>  > "Starting ntpd".
>  
>  
>  I get everywhere 'OK', but it still doesn't work...
>  Here's the log, I was just typing the commands one by one:
>  
>  [root@frontend ~]# date
>  Fri Sep  7 23:21:29 MSD 2007
>  [root@frontend ~]# service ntpd restart
>  Shutting down ntpd:                                        [  OK  ]
>  ntpd: Synchronizing with time server:                      [  OK  ]
>  Starting ntpd:                                             [  OK  ]
>  [root@frontend ~]# ntpq -p
>       remote           refid      st t when poll reach   delay   offset  jitter
>  ==============================================================================
>   andromeda.cs.pu .CDMA.           1 u    6   64    1  187.712  -46.448   0.002
>   banana.irc.gr   192.36.134.25    2 u    5   64    1  160.135  -67.667   0.002
>   b.pool.ntp.uq.e 130.102.152.7    2 u    4   64    1  550.855    4.548   0.002
>  [root@frontend ~]# ntpstat
>  unsynchronised
>    time server re-starting
>     polling server every 64 s
>  [root@frontend ~]# date
>  Fri Sep  7 23:21:59 MSD 2007
>  [root@frontend ~]#
>  
>  Here's the corresponding part of /var/log/messages:
>  
>  Sep  7 23:21:35 frontend ntpd[4088]: ntpd exiting on signal 15
>  Sep  7 23:21:39 frontend ntpdate[4115]: step time server 66.187.224.4 offset -0.344342
> sec
>  Sep  7 23:21:39 frontend ntpd[4117]: ntpd 4.2.4p2(a)1.1495-o Tue Aug 21 14:07:56 UTC 2007
> (1)
>  Sep  7 23:21:39 frontend ntpd[4118]: precision = 2.000 usec
>  Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #0 wildcard, 0.0.0.0#123
> Disabled
>  Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #1 wildcard, ::#123 Disabled
>  Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #2 lo, ::1#123 Enabled
>  Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #3 eth0,
> fe80::230:5ff:fe22:857#123 Enabled
>  Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
>  Sep  7 23:21:39 frontend ntpd[4118]: Listening on interface #5 eth0, 172.23.0.133#123
> Enabled
>  Sep  7 23:21:39 frontend ntpd[4118]: kernel time sync status 0040
>  Sep  7 23:21:39 frontend ntpd[4118]: frequency initialized 0.000 PPM from
> /var/lib/ntp/drift
>  
>  
>  
>  
>  > Just for your info, here are my files:
>  
>  > [root@golem3 ~]# cat /etc/ntp/ntpservers
>  > clock.redhat.com
>  > clock2.redhat.com
>  > [root@golem3 ~]# cat /etc/ntp/step-tickers
>  > clock.redhat.com
>  > clock2.redhat.com
>  
>  > Works fine for me.
>  
>  I have the same now. And it doesn't work. And I see no reason...
>  
>  
>  > You do have port 123 open on your firewall, right?
>  
>  I have my firewall disabled at all. So all ports are open.
>  And other PCs on my home LAN are syncing just fine, so it's not a
>  provider's fault. 
Ok, final push.  Edit /etc/sysconfig/ntpd and add "-x" to the OPTIONS
line:

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
         ^^
         Add there

Finally, do "service ntpd restart" and it should fire up.

----------------------------------------------------------------------
- Rick Stevens, Principal Engineer             rstevens(a)internap.com -
- CDN Systems, Internap, Inc.                http://www.internap.com -
-                                                                    -
-     There are only 10 kinds of people in the world -- those who    -
-                 understand binary and those who don't              -
----------------------------------------------------------------------

[Andrew Junev]

Saturday, September 8, 2007, 12:30:07 AM, you wrote:

>  Ok, final push.  Edit /etc/sysconfig/ntpd and add "-x" to
> the OPTIONS
>  line: 
>  # Drop root to id 'ntp:ntp' by default.
>  OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
>           ^^
>           Add there 
>  Finally, do "service ntpd restart" and it should fire up.
I just did all that. No luck... :-(

Sep  8 11:33:50 frontend ntpd[4118]: ntpd exiting on signal 15
Sep  8 11:25:13 frontend ntpdate[5868]: step time server 66.187.233.4 offset -521.560811
sec
Sep  8 11:25:13 frontend ntpd[5870]: ntpd 4.2.4p2(a)1.1495-o Tue Aug 21 14:07:56 UTC 2007
(1)
Sep  8 11:25:13 frontend ntpd[5871]: precision = 2.000 usec
Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #0 wildcard, 0.0.0.0#123
Disabled
Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #1 wildcard, ::#123 Disabled
Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #2 lo, ::1#123 Enabled
Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #3 eth0,
fe80::230:5ff:fe22:857#123 Enabled
Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #5 eth0, 172.23.0.133#123
Enabled
Sep  8 11:25:13 frontend ntpd[5871]: kernel time sync status 0040
Sep  8 11:25:14 frontend ntpd[5871]: frequency initialized 0.000 PPM from
/var/lib/ntp/drift

ntpd is still not syncing...

What else can I do?!

[Frank Cox]

On Sat, 08 Sep 2007 11:30:39 +0400
Andrew Junev <a-j(a)a-j.ru&gt; wrote:

>  ntpd is still not syncing...
>  
>  What else can I do?! 
As a wild guess (and I'm not sure if anyone else has suggested this to you) do
you have any sort of a firewall that could be blocking the connection that ntpd
is trying to make?

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

[Andrew Junev]

>  As a wild guess (and I'm not sure if anyone else has suggested
> this to you) do
>  you have any sort of a firewall that could be blocking the connection that ntpd
>  is trying to make? 
Nope! I don't have any firewalls. I have other PCs running Fedora
Core 6 on my home LAN with ntp working on all of them just fine. It's
only this machine (the only one with Fedora 7) that is not syncing...

[Gene Heskett]

On Saturday 08 September 2007, Andrew Junev wrote:
> > As a wild guess (and I'm not sure if anyone else has
> suggested this to
> > you) do you have any sort of a firewall that could be blocking the
> > connection that ntpd is trying to make?
>
> Nope! I don't have any firewalls. I have other PCs running Fedora
> Core 6 on my home LAN with ntp working on all of them just fine. It's
> only this machine (the only one with Fedora 7) that is not syncing... 
And that fairly screams that its an selinux problem, one that setting it to 
permissive mode does NOT fix in my experience.

Append to the end of the kernel arguments line in your grub.conf, 'selinux=0' 
without the quotes and reboot.  If that fixes it, throw it back at the 
selinux mailing list where Stephen Smalley hangs out.

Me, I have a good natting router and firewall, and no desire to spend 3 weeks 
fixing all the gotcha's selinux throws up, so the total disable, and that is 
the only known way to do it I show above, has been part of my personal bag of
headache pills for quite a while now.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
You are in a maze of little twisting passages, all different.

[Andrew Junev]

Saturday, September 8, 2007, 12:37:01 PM, you wrote:

>  And that fairly screams that its an selinux problem, one that setting
> it to
>  permissive mode does NOT fix in my experience. 
I disabled selinux already during the installation.

>  Append to the end of the kernel arguments line in your grub.conf,
> 'selinux=0'
>  without the quotes and reboot.  If that fixes it, throw it back at the
>  selinux mailing list where Stephen Smalley hangs out. 
Hmmm... Although I disabled selinux, I didn't have 'selinux=0' in my
grub.conf. Probably it gets disabled somewhere else. Anyway, I added
this parameter and rebooted the system. Still no changes in ntpd
behavior.

Sep  8 12:56:10 frontend_light ntpdate[1943]: step time server 66.187.233.4 offset
-65.237699 sec
Sep  8 12:56:10 frontend_light ntpd[1945]: ntpd 4.2.4p2(a)1.1495-o Tue Aug 21 14:07:56 UTC
2007 (1)
Sep  8 12:56:10 frontend_light ntpd[1946]: precision = 1.000 usec
Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #0 wildcard, 0.0.0.0#123
Disabled
Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #1 wildcard, ::#123
Disabled
Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #2 lo, ::1#123 Enabled
Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #3 eth0,
fe80::230:5ff:fe22:857#123 Enabled
Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #4 lo, 127.0.0.1#123
Enabled
Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #5 eth0,
172.23.0.133#123 Enabled
Sep  8 12:56:10 frontend_light ntpd[1946]: kernel time sync status 0040
Sep  8 12:56:11 frontend_light ntpd[1946]: frequency initialized 0.000 PPM from
/var/lib/ntp/drift


On my Fedora 6 machine ntpd is working fine:

 6 Sep 23:13:05 ntpd[2770]: synchronized to 128.10.252.10, stratum 2
 7 Sep 03:20:43 ntpd[2770]: synchronized to 130.89.164.77, stratum 2
 7 Sep 04:46:10 ntpd[2770]: synchronized to 128.10.252.10, stratum 2
 7 Sep 06:47:57 ntpd[2770]: synchronized to 130.89.164.77, stratum 2
 7 Sep 07:53:58 ntpd[2770]: synchronized to 128.10.252.10, stratum 2


[root@frontend_light ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 balthazar.tihld 192.36.144.22    2 u   15   64  377   41.875  -3341.6 1648.40
 bbs.csie.ncyu.e 220.130.158.71   3 u   13   64  377  364.927  -3354.8 1646.82
 hobbes.macvaerk 193.162.142.71   3 u   14   64  377  128.439  -3332.9 1608.39
[root@frontend_light ~]# ntpstat
unsynchronised
  time server re-starting
   polling server every 64 s
[root@frontend_light ~]#

[Gene Heskett]

On Saturday 08 September 2007, Andrew Junev wrote:
> Saturday, September 8, 2007, 12:37:01 PM, you wrote:
> > And that fairly screams that its an selinux problem, one that setting it
> > to permissive mode does NOT fix in my experience.
>
> I disabled selinux already during the installation.
>
> > Append to the end of the kernel arguments line in your grub.conf,
> > 'selinux=0' without the quotes and reboot.  If that fixes it, throw it
> > back at the selinux mailing list where Stephen Smalley hangs out.
>
> Hmmm... Although I disabled selinux, I didn't have 'selinux=0' in my
> grub.conf. Probably it gets disabled somewhere else. 
No, that is the only way to shut it completely off.  This is a known FC7 
problem.  Setting it to be permissive as you did in the install is not 
sufficient to allow ntp to work.

> Anyway, I added 
> this parameter and rebooted the system. Still no changes in ntpd
> behavior.
>
> Sep  8 12:56:10 frontend_light ntpdate[1943]: step time server 66.187.233.4
>  offset -65.237699 sec Sep  8 12:56:10 frontend_light ntpd[1945]: ntpd
>  4.2.4p2(a)1.1495-o Tue Aug 21 14:07:56 UTC 2007 (1) Sep  8 12:56:10
>  frontend_light ntpd[1946]: precision = 1.000 usec
> Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #0
>  wildcard, 0.0.0.0#123 Disabled Sep  8 12:56:10 frontend_light ntpd[1946]:
>  Listening on interface #1 wildcard, ::#123 Disabled Sep  8 12:56:10
>  frontend_light ntpd[1946]: Listening on interface #2 lo, ::1#123 Enabled
>  Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #3 eth0,
>  fe80::230:5ff:fe22:857#123 Enabled Sep  8 12:56:10 frontend_light
>  ntpd[1946]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Sep  8
>  12:56:10 frontend_light ntpd[1946]: Listening on interface #5 eth0,
>  172.23.0.133#123 Enabled Sep  8 12:56:10 frontend_light ntpd[1946]: kernel
>  time sync status 0040 Sep  8 12:56:11 frontend_light ntpd[1946]: frequency
>  initialized 0.000 PPM from /var/lib/ntp/drift
>
>
> On my Fedora 6 machine ntpd is working fine:
>
>  6 Sep 23:13:05 ntpd[2770]: synchronized to 128.10.252.10, stratum 2
>  7 Sep 03:20:43 ntpd[2770]: synchronized to 130.89.164.77, stratum 2
>  7 Sep 04:46:10 ntpd[2770]: synchronized to 128.10.252.10, stratum 2
>  7 Sep 06:47:57 ntpd[2770]: synchronized to 130.89.164.77, stratum 2
>  7 Sep 07:53:58 ntpd[2770]: synchronized to 128.10.252.10, stratum 2
>
>
> [root@frontend_light ~]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset 
>  jitter
>  ===========================================================================
> === balthazar.tihld 192.36.144.22    2 u   15   64  377   41.875  -3341.6
>  1648.40 bbs.csie.ncyu.e 220.130.158.71   3 u   13   64  377  364.927 
>  -3354.8 1646.82 hobbes.macvaerk 193.162.142.71   3 u   14   64  377 
>  128.439  -3332.9 1608.39 [root@frontend_light ~]# ntpstat
> unsynchronised
>   time server re-starting 
And why is it restarting?  I don't know the answer there, but someplace in a 
log, there should be a clue.


>    polling server every 64 s
> [root@frontend_light ~]# 


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Never underestimate the bandwidth of a station wagon full of tapes.
		-- Dr. Warren Jackson, Director, UTCS

[Andrew Junev]

Saturday, September 8, 2007, 1:28:42 PM, you wrote:

> >Hmmm... Although I disabled selinux, I didn't have
> 'selinux=0' in my
> >grub.conf. Probably it gets disabled somewhere else. 
>  No, that is the only way to shut it completely off.  This is a known
> FC7
>  problem.  Setting it to be permissive as you did in the install is not
>  sufficient to allow ntp to work. 
As I remember, during installation there was an option to set selinux
to permissive mode or to disable it. I choose 'Disable'.
Anyway, now I have 'selinux=0' parameter in grub.conf, so it should be
disabled.

> >Sep  8 12:56:10 frontend_light ntpdate[1943]: step time server
> 66.187.233.4
> > offset -65.237699 sec Sep  8 12:56:10 frontend_light ntpd[1945]: ntpd
> > 4.2.4p2(a)1.1495-o Tue Aug 21 14:07:56 UTC 2007 (1) Sep  8 12:56:10
> > frontend_light ntpd[1946]: precision = 1.000 usec
> >Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #0
> > wildcard, 0.0.0.0#123 Disabled Sep  8 12:56:10 frontend_light ntpd[1946]:
> > Listening on interface #1 wildcard, ::#123 Disabled Sep  8 12:56:10
> > frontend_light ntpd[1946]: Listening on interface #2 lo, ::1#123 Enabled
> > Sep  8 12:56:10 frontend_light ntpd[1946]: Listening on interface #3 eth0,
> > fe80::230:5ff:fe22:857#123 Enabled Sep  8 12:56:10 frontend_light
> > ntpd[1946]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Sep  8
> > 12:56:10 frontend_light ntpd[1946]: Listening on interface #5 eth0,
> > 172.23.0.133#123 Enabled Sep  8 12:56:10 frontend_light ntpd[1946]: kernel
> > time sync status 0040 Sep  8 12:56:11 frontend_light ntpd[1946]: frequency
> > initialized 0.000 PPM from /var/lib/ntp/drift
> >
> >
> >[root@frontend_light ~]# ntpq -p
> >     remote           refid      st t when poll reach   delay   offset 
> > jitter
> > ===========================================================================
> >=== balthazar.tihld 192.36.144.22    2 u   15   64  377   41.875  -3341.6
> > 1648.40 bbs.csie.ncyu.e 220.130.158.71   3 u   13   64  377  364.927 
> > -3354.8 1646.82 hobbes.macvaerk 193.162.142.71   3 u   14   64  377 
> > 128.439  -3332.9 1608.39 [root@frontend_light ~]# ntpstat
> >unsynchronised
> >  time server re-starting 
>  And why is it restarting?  I don't know the answer there, but
> someplace in a
>  log, there should be a clue. 
I don't know either... Above I provided all the logs regarding ntpd.
There's nothing special, really... It's almost the same as on my
Fedora Core 6 machine, except that ntp here is not getting synced...

[Andy Green]

Somebody in the thread at some point said:

> >> 128.439  -3332.9 1608.39 [root@frontend_light ~]# ntpstat
> >> unsynchronised
> >>  time server re-starting 
Is ntpd running after this?

# ps -Af | grep ntpd

> > And why is it restarting?  I don't know the answer there, but
> someplace in a
> > log, there should be a clue.
>  
>  I don't know either... Above I provided all the logs regarding ntpd.
>  There's nothing special, really... It's almost the same as on my
>  Fedora Core 6 machine, except that ntp here is not getting synced... 
I guess I would strace ntpd, then.  If it was selinux, you'd be seeing
avc messages in your /var/log/messages anyway.

# service ntpd stop
# strace -f ntpd -u ntp:ntp -p /var/run/ntpd.pid -g

-Andy

[Andrew Junev]

Saturday, September 8, 2007, 2:03:42 PM, you wrote:

>  Somebody in the thread at some point said: 
> >>> 128.439  -3332.9 1608.39 [root@frontend_light ~]#
> ntpstat
> >>> unsynchronised
> >>>  time server re-starting 
>  Is ntpd running after this? 
>  # ps -Af | grep ntpd 
Yes:

[root@frontend_light ~]# ps -Af | grep ntpd
ntp       1946     1  0 12:56 ?        00:00:00 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid
root      2608  2458  0 14:08 pts/0    00:00:00 grep ntpd



>  I guess I would strace ntpd, then.  If it was selinux, you'd be
> seeing
>  avc messages in your /var/log/messages anyway. 
>  # service ntpd stop
>  # strace -f ntpd -u ntp:ntp -p /var/run/ntpd.pid -g 
Ok, I did that. Got lot's of information on the screen. I don't
understand most of it... :(  The output is attached.

There's a strange message inside:

recvmsg(21, 0xbff67df4, 0)              = -1 EAGAIN (Resource temporarily unavailable)

I don't think it's normal.
But I can't also say it's something that is causing the problem...

[Andy Green]

Somebody in the thread at some point said:

>  recvmsg(21, 0xbff67df4, 0)              = -1 EAGAIN (Resource
> temporarily unavailable)
>  
>  I don't think it's normal.
>  But I can't also say it's something that is causing the problem... 
No I think that is normal: I see it here.  I was kind of hoping ntpd
would drop dead in an interesting way.  This one is also seen here
(lines 234 and 1167):

adjtimex({modes=ADJ_OFFSET|ADJ_FREQUENCY, offset=0, freq=0, maxerror=16,
esterror=16, status=STA_UNSYNC, constant=4, precision=1,
tolerance=33554432, time={1189246336, 574721}, tick=10000, ppsfreq=0,
jitter=0, shift=0, stabil=0, jitcnt=0, calcnt=0, errcnt=0, stbcnt=0}) =
5 (TIME_ERROR)

However, what isn't seen here (where ntpd works) is ipv6 support.  You
appear to have it enabled

1228: open("/proc/net/if_inet6", O_RDONLY)    = 5

whereas I have it turned off

open("/proc/net/if_inet6", O_RDONLY)    = -1 ENOENT (No such file or
directory)

If you want to look at killing it, add this to /etc/modprobe.conf

install ipv6 /bin/true

and reboot.

-Andy

[Andrew Junev]

Saturday, September 8, 2007, 2:50:31 PM, you wrote:
>  However, what isn't seen here (where ntpd works) is ipv6 support.
>  You
>  appear to have it enabled 
>  1228: open("/proc/net/if_inet6", O_RDONLY)    = 5 
>  whereas I have it turned off 
>  open("/proc/net/if_inet6", O_RDONLY)    = -1 ENOENT (No
> such file or
>  directory) 
>  If you want to look at killing it, add this to /etc/modprobe.conf
>  install ipv6 /bin/true 
>  and reboot. 
Did that. No visible changes to ntpd behavior....

New strace attached...

:-(

[Andy Green]

Somebody in the thread at some point said:

> > install ipv6 /bin/true
>  
> > and reboot.
>  
>  Did that. No visible changes to ntpd behavior....
>  
>  New strace attached... 
Sorry mate, didn't see anything that gave me an idea.

-Andy

[Gene Heskett]

On Saturday 08 September 2007, Andy Green wrote:
> Somebody in the thread at some point said:
> >>> 128.439  -3332.9 1608.39 [root@frontend_light ~]# ntpstat
> >>> unsynchronised
> >>>  time server re-starting
>
> Is ntpd running after this?
>
> # ps -Af | grep ntpd
>
> >> And why is it restarting?  I don't know the answer there, but someplace
> >> in a log, there should be a clue.
> >
> > I don't know either... Above I provided all the logs regarding ntpd.
> > There's nothing special, really... It's almost the same as on my
> > Fedora Core 6 machine, except that ntp here is not getting synced...
>
> I guess I would strace ntpd, then.  If it was selinux, you'd be seeing
> avc messages in your /var/log/messages anyway. 
I did not see any avc msgs in my logs at the time I installed F7 on my lappy. 
IIRC I had to strace it myself to see that, but the message I saw in the 
strace output never made it to the logs.

> # service ntpd stop
> # strace -f ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
>
> -Andy 


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
interrupt configuration error

[Mikkel]

Andrew Junev wrote:
> > As a wild guess (and I'm not sure if anyone else has
> suggested this to you) do
> > you have any sort of a firewall that could be blocking the connection that ntpd
> > is trying to make?
>  
>  Nope! I don't have any firewalls. I have other PCs running Fedora
>  Core 6 on my home LAN with ntp working on all of them just fine. It's
>  only this machine (the only one with Fedora 7) that is not syncing...
>   
Dumb question - what kernel are the FC6 systems running, and what
kernel is the F7 system running? Could there be a problem on your
system with the new "tickless" kernels and ntpd?

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Andrew Junev]

Saturday, September 8, 2007, 5:42:37 PM, you wrote:

>  Dumb question - what kernel are the FC6 systems running, and what
>  kernel is the F7 system running? Could there be a problem on your
>  system with the new "tickless" kernels and ntpd? 
Fedora Core 6 uses 2.6.20-1.2962.fc6
Fedora 7 uses 2.6.22.4-65.fc7

I also thought the kernel might be a problem. But for some reason
noone else has it. It makes me think it's something with the
configuration. But in fact it's a clean install of Fedora 7 with all
the option set to its default values (except for the firewall and
selinux which are disabled) and just ntp turned on...

Can it be a problem with my hardware (I mean motherboard)? Is there a
way to trace it?

Thanks!

[Nigel Henry]

On Saturday 08 September 2007 21:44, Andrew Junev wrote:
>  Saturday, September 8, 2007, 5:42:37 PM, you wrote:
>  > Dumb question - what kernel are the FC6 systems running, and what
>  > kernel is the F7 system running? Could there be a problem on your
>  > system with the new "tickless" kernels and ntpd?
>
>  Fedora Core 6 uses 2.6.20-1.2962.fc6
>  Fedora 7 uses 2.6.22.4-65.fc7
>
>  I also thought the kernel might be a problem. But for some reason
>  noone else has it. It makes me think it's something with the
>  configuration. But in fact it's a clean install of Fedora 7 with all
>  the option set to its default values (except for the firewall and
>  selinux which are disabled) and just ntp turned on...
>
>  Can it be a problem with my hardware (I mean motherboard)? Is there a
>  way to trace it?
>
>  Thanks! 
I've spent quite a bit of time looking into this problem today, and there 
appears to be some sort of problem with ntp on Fedora 7. My Fedora 7 is on a 
machine that gets it's time from my other machine, which gets it's time from 
the Internet. i've run ntpq> pe every few minutes, and the F7 machine gets 
the time synchronized from the other machine, but never polls less than every 
64 secs. it then loses the synch, and starts afresh. It eventually achieves a 
"reach" of 377, and is synched again, but some minutes lates, again loses 
synch.

I went into /etc/ntp.conf, commented out the 192.168.0.230 server line, and 
uncommented the commented out default server lines. Stopped, and started the 
ntp daemon, and got the same results. After some time synchronization is 
lost.

By contrast, booting FC5 on the same machine, which has 192.168.0.230 as the 
server line in /etc/ntp.conf, I have no problems. When it's synched it's 
polling every 64 secs, and progressively polls at longer intervals, as below. 
This is over about some 2hrs.

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.0.230   80.127.4.179     2 u   56   64    3    0.543  7201255   1.797
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.0.230   80.127.4.179     2 u   55   64   17    0.371   -3.387   1.807
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u   51   64  177    0.351   -5.402   2.832
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  103  128  377    0.316  -18.440   4.938
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  119  128  377    0.316  -18.440   4.479
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u   58  128  377    0.364  -23.597   0.662

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u   27  128  377    0.376  -24.385   1.127
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  108  128  377    0.351  -22.874   1.609
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u    7  128  377    0.351  -22.874   2.574
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u   52  128  377    0.382  -20.714   2.112
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  170  256  377    0.382  -20.714   2.280
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  112  256  377    0.391  -17.659   3.253
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  139  256  377    0.359  -10.552   1.658
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  200  256  377    0.392   -7.807   1.354
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.230   80.127.4.179     2 u  198 1024  377    0.480    5.336   1.668
ntpq>

The kernel I booted FC5 with is 2.6.17-1.2174_FC5, and the kernel I was using 
on Fedora 7, was 2.6.22.6. A realtime kernel from planetccrma.

I know I'm not being of any help. Just some observations from my machines, but 
there does appear to be some problem with NTP on Fedora 7 from my own 
observations.

Sorry I can't offer  a fix.

Nigel.

[Frank Cox]

On Sat, 08 Sep 2007 12:22:36 +0400
Andrew Junev <a-j(a)a-j.ru&gt; wrote:


>  Nope! I don't have any firewalls. I have other PCs running
> Fedora
>  Core 6 on my home LAN with ntp working on all of them just fine. It's
>  only this machine (the only one with Fedora 7) that is not syncing... 
I wonder if ntpd has somehow become "stuck" looking for a ntp server that's
not
responding.

You could try specifying an individual ntp server instead of the default pool
options.

I personally use time.windows.com because it's easy to remember, and I figure
they can afford the bandwidth.  (Plus I enjoy the irony, of course.)

Along the same line, it might be interesting to watch your network traffic when
you crank up ntpd.  On the relatively rare occasions where I want to do this, I
have lately been using ettercap (yum install gtk-ettercap) and it works rather
well.  See if ntpd is actually trying to connect with anything and if it is,
to what?  Are there signs of life on the other end?  Is something blocking the
connection? (If so, try dig and see where it dies.) And so on...

As a last resort, you could always just put rdate into a cron job and forget
ntpd altogether.  Back in the "dark ages" I used to use rdate on my computers
until I either figured out how to set up ntpd or it started working by magic; I
can't remember which, actually.  rdate in a cron job will set your clock just
like ntpd can -- the disadvantage is that you don't get the ongoing drift
correction, though that's not usually a really big hairy deal unless you're
doing something that's very dependent on super-accurate timekeeping.

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

[Tim]

On Sat, 2007-09-08 at 08:58 -0600, Frank Cox wrote:
>  I personally use time.windows.com because it's easy to remember,
> and I
>  figure they can afford the bandwidth.  (Plus I enjoy the irony, of
>  course.)  
It used to be that they were less than a good time source, with frequent
very bad errors.  I wonder if that's still the case?

-- 
[tim@bigblack ~]$ uname -ipr
2.6.22.4-65.fc7 i686 i386

Using FC 4, 5, 6 & 7, plus CentOS 5.  Today, it's FC7.

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Frank Cox]

On Sun, 09 Sep 2007 19:25:10 +0930
Tim <ignored_mailbox(a)yahoo.com.au&gt; wrote:

>  It used to be that they were less than a good time source, with
> frequent
>  very bad errors.  I wonder if that's still the case? 
As far as I'm aware, that situation was resolved 3 or 4 (or more?) years back.
At least I haven't read about any problems, or noticed any inaccuracy since I
started using it on my systems.

Which doesn't necessarily mean anything, of course...

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

[Gene Heskett]

On Saturday 08 September 2007, Andrew Junev wrote:
> Saturday, September 8, 2007, 12:30:07 AM, you wrote:
> > Ok, final push.  Edit /etc/sysconfig/ntpd and add "-x" to the OPTIONS
> > line:
> >
> > # Drop root to id 'ntp:ntp' by default.
> > OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
> >          ^^
> >          Add there
> >
> > Finally, do "service ntpd restart" and it should fire up.
>
> I just did all that. No luck... :-(
>
> Sep  8 11:33:50 frontend ntpd[4118]: ntpd exiting on signal 15
> Sep  8 11:25:13 frontend ntpdate[5868]: step time server 66.187.233.4 offset
>  -521.560811 sec 
>  Sep  8 11:25:13 frontend ntpd[5870]: ntpd 4.2.4p2(a)1.1495-o 
>  Tue Aug 21 14:07:56 UTC 2007 (1) 
>  Sep  8 11:25:13 frontend ntpd[5871]: precision = 2.000 usec
> Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #0 wildcard,
>  0.0.0.0#123 Disabled 
>  Sep  8 11:25:13 frontend ntpd[5871]: Listening on 
>  interface #1 wildcard, ::#123 Disabled 
>  Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #2 lo, ::1#123  
Enabled

>  Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #3 eth0, 
fe80::230:5ff:fe22:857#123
>  Enabled 
>  Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #4 lo, 
>  127.0.0.1#123 Enabled 
>  Sep  8 11:25:13 frontend ntpd[5871]: Listening on interface #5 eth0, 
172.23.0.133#123 Enabled 
>  Sep  8 11:25:13 frontend ntpd[5871]: kernel time sync status 0040
>  Sep  8 11:25:14 frontend ntpd[5871]: frequency initialized 0.000 PPM from
>  /var/lib/ntp/drift
>
> ntpd is still not syncing...
>
> What else can I do?! 
Are you using pool.ntp.org as the src?  Can you ping them, getting an 
apparently random address selection out of a dozen or so choices?

Make sure its getting through any routers you may be using.  You should see 
something like this in a "grep ntp /var/log/messages":
Sep  2 22:30:15 coyote ntpd[4872]: kernel time sync status 0040
Sep  2 22:30:16 coyote ntpd[4872]: frequency initialized 158.069 PPM 
from /var/lib/ntp/drift
Sep  2 22:33:28 coyote ntpd[4872]: synchronized to 198.60.22.240, stratum 1
Sep  2 22:33:28 coyote ntpd[4872]: kernel time sync enabled 0001
Sep  2 23:38:39 coyote ntpd[4872]: synchronized to 192.87.106.2, stratum 1
Sep  2 23:44:01 coyote ntpd[4872]: synchronized to 198.60.22.240, stratum 1
Sep  3 00:45:28 coyote ntpd[4872]: synchronized to 192.87.106.2, stratum 1
Sep  3 00:54:08 coyote ntpd[4872]: synchronized to 198.60.22.240, stratum 1
Sep  6 04:51:26 coyote ntpd[4872]: synchronized to 192.87.106.2, stratum 1
Sep  6 07:26:48 coyote ntpd[4872]: synchronized to 198.60.22.240, stratum 1
Sep  6 08:50:32 coyote ntpd[4872]: synchronized to 192.87.106.2, stratum 1
Sep  6 14:15:46 coyote ntpd[4872]: synchronized to 198.60.22.240, stratum 1
Sep  6 22:30:11 coyote ntpd[4872]: synchronized to 192.87.106.2, stratum 1
Sep  7 01:04:31 coyote ntpd[4872]: synchronized to 198.60.22.240, stratum 1


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Certainly the game is rigged.

Don't let that stop you; if you don't bet, you can't win.
		-- Robert Heinlein, "Time Enough For Love"

[Mike C]

Andrew Junev <a-j <at> a-j.ru> writes:

>  [root <at> frontend ~]# service ntpd restart
>  Shutting down ntpd:                                        [  OK  ]
>  ntpd: Synchronizing with time server:                      [  OK  ]
>  Starting ntpd:                                             [  OK  ]
>  [root <at> frontend ~]# ntpq -p
>       remote           refid      st t when poll reach   delay   offset  jitter
>  ==============================================================================
>   andromeda.cs.pu .CDMA.           1 u    6   64    1  187.712  -46.448   0.002
>   banana.irc.gr   192.36.134.25    2 u    5   64    1  160.135  -67.667   0.002
>   b.pool.ntp.uq.e 130.102.152.7    2 u    4   64    1  550.855    4.548   0.002
>  [root <at> frontend ~]# ntpstat
>  unsynchronised
>    time server re-starting
>     polling server every 64 s 
I have always found this is the usual message you get running ntpstat immediately
after running service ntpd restart.

However you I wait a few minutes then try ntpstat again then it slowly syncs the 
time and after a number of minutes you will get something more like:
[root@home1 ~]# ntpstat
synchronised to NTP server (158.43.128.66) at stratum 3
   time correct to within 53 ms
   polling server every 1024 s

It initially sets the poll time to every 64 sec and then slowly changes to every
1024 sec.

HTH
Mike

[ne...]

On 9/7/07, Andrew Junev <a-j(a)a-j.ru&gt; wrote:

>  Ok, I checked the /etc/ntp/ntpservers and they are the same on both
>  Fedora Core 6 and Fedora 7 machines containing just 2 lines:
>  clock.redhat.com
>  clock2.redhat.com 
I left those alone and changed /etc/ntp.conf to use
pool.ntp.org.
Since I am in the UK I use:
server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org

HTH
ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.

[Nigel Henry]

On Friday 07 September 2007 18:22, Andrew Junev wrote:
>  Dear All,
>
>  I have just installed Fedora 7 on a P-III machine. Firewall and
>  SeLinux are both disabled. But I still can't get ntp running...
>  I searched the net but couldn't find the right direction...
>
>  Here's what I have:
>  [root@frontend ~]# ntpstat
>  unsynchronised
>    time server re-starting
>     polling server every 64 s
>  [root@frontend ~]# ntpq -p
>       remote           refid      st t when poll reach   delay   offset 
>  jitter
>  ===========================================================================
> === 218-185-224-8-b 128.250.36.3     2 u   20   64  377  358.766  -907853
>  2890.12 218-185-224-9-b 128.250.33.242   2 u   30   64  377  372.321 
>  -907746 2867.96 212.57.153.17   195.2.64.5       2 u   47   64  377  
>  81.773  -907581 2879.97 [root@frontend ~]# ntptrace 212.57.153.17
>  212.57.153.17: stratum 2, offset -0.013595, synch distance 0.096890
>  ntp0.zenon.net: stratum 1, offset 0.003489, synch distance 0.009358, refid
>  'GPS' [root@frontend ~]#
>
>  ntp.conf exists and was not changed since its creation during install.
>  I have another machine running Fedora Core 6 and the ntp works there
>  just fine! On that machine I didn't do anything special, everything
>  worked right after system installation. I tried to compare the
>  settings but found no difference... 
<snip>
>  Best regards,
>   Andrew 
Hi Andrew. Sorry to here about your problems.

I set up NTP about 2 years ago on my 2 machines, with help from the ntp 
questions mailing list. The default /etc/ntp.conf has a lot of uncommented 
lines, and I was told that in most cases all you really need are the server 
lines, and the driftfile one. I commented out all the other lines, and just 
left the server lines that I'd set up, and the driftfile line. Started the 
ntp daemon, ran ntpq> pe from time to time, and eventually the servers 
synched up. It does take a bit of time to synch, and many hours before the 
driftfile "stabilises", for want of a better word.

As a matter of consideration for the Internet time servers it is also 
suggested, if you have a few machines on a LAN, to set one machine up to 
access Internet time servers, and set up the other machines to get their time 
rom that machine, which is what I did.

I only have 2 machines on the LAN, but with a bunch of distros that run on 
each of them, so I set up /etc/ntp.conf for all the distros on machine "A" 
with just the Internet timeserver lines, and the driftfile one.

All my distros have static IP addresses, so for the distros on machine "B" the 
only lines uncommented are the server lines, and the driftfile one.

As an example for Fedora 7 on machine "B", and as I havn't got around to 
adding the lines for the other distros that run on machine "A", there is just 
one server line.
server 192.168.0.230
plus the driftfile one of course.

Both machines access the Internet by means of a Smoothwall Express2 firewall, 
and serial modem. The Smoothwall sorts out it's own time, and checks every 
3hrs from a range of Internet time servers.

By the way for the 1st time with the Fedora 7 install, I've left Selinux 
enabled (enforcing), and am having no problems with ntp on it.

Just some comments on my setup, that may or may not  be helpfull.

Nigel.