FC4 NTPD problem

[jdow]

From: "Vikram Goyal" <vikigoyal at gmail.com>
>
>> This is a distillation of my ntp.conf file:
>> ===8<---
>> fudge   127.127.1.0 stratum 10
>>
>> server xxxxxxx.xxx
>> server xxxxxxx.xxx
>> server xxxxxxx.xxx
>>
>> driftfile /etc/ntp/drift
>> multicastclient                 # listen on default 224.0.1.1
>> broadcastdelay  0.008
>>
>> #restrict default ignore
>>
>> logfile /var/log/ntp
>> restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery
>> restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery
>> restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery
>> ===8<---
>>
>> It is the evolutionary product of my initially starting using xntpd
>> back when it was an experimental protocol. It has the advantage that
>> "it works for me." {^_-}
>>
>> {^_^}
>>
>
> Hi,
>
> I have tried it many times with the firewall down also.
>
> See...
>
> [root at fc4host ~]# service iptables stop
> Flushing firewall rules:                                   [  OK  ]
> Setting chains to policy ACCEPT: mangle nat filter         [  OK  ]
> Unloading iptables modules:                                [  OK  ]
> [root at fc4host ~]# iptables -L
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> [root at fc4host ~]# service ntpd restart
> Shutting down ntpd:                                        [  OK  ]
> ntpd: Synchronizing with time server:                      [FAILED]
> Starting ntpd:                                             [  OK  ]
> [root at fc4host ~]# iptables -L
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> [root at fc4host ~]#
>
> As it proves firewall is not the issue. And I am able to sync with
> ntpdate. See...
>
> -----------------------------------------------------------------------
> [root at fc4host ~]# ntpdate -uvs clock2.redhat.com
>
> Sep 24 10:13:37 fc4host ntpd[12979]: ntpd exiting on signal 15
> Sep 24 10:16:16 fc4host ntpdate[14441]: ntpdate 4.2.0a at 1.1190-r Thu Apr
> 14 07:47:27 EDT 2005 (1)
> Sep 24 10:16:15 fc4host ntpdate[14441]: step time server 66.187.224.4 
> offset -1.927487 sec

This proves nothing about the firewall. The way to prove that is to
stop ntp and use "ntpdate -vs clock2.redhat.com". That way you will
be using the normal ntp port. Also look at the syslog file to see if
there are firewall reports of blockage.

> -----------------------------------------------------------------------
> [root at fc4host ~]# ntpdate -uvs 0.pool.ntp.org
>
> Sep 24 10:18:07 fc4host ntpdate[14452]: ntpdate 4.2.0a at 1.1190-r Thu Apr
> 14 07:47:27 EDT 2005 (1)
> Sep 24 10:18:08 fc4host ntpdate[14452]: adjust time server 64.109.43.141 
> offset 0.002379 sec

Repeat - leave off the u and run the test with ntpd stopped.

> -----------------------------------------------------------------------
> [root at fc4host ~]# ntpdate -uvs clock2.redhat.com
>
> Sep 24 10:19:42 fc4host ntpdate[14453]: ntpdate 4.2.0a at 1.1190-r Thu Apr
> 14 07:47:27 EDT 2005 (1)
> Sep 24 10:19:44 fc4host ntpdate[14453]: adjust time server 66.187.224.4 
> offset 0.007559 sec
> -----------------------------------------------------------------------
>
> And while the firewall is up.
>
> Anyways, I just wanted to know exactly what's stopping the daemon.

It should not be stopping. So there is something messed up somewhere.
What does your "/etc/ntp.conf" file look like with the commented out
items stripped out? There might be something interesting in that file.

{^_^}