Hey there, read what I could, tested, but can't figure this. We are switching to use one time server to, well, get time, and the other box's to look at him for the sync.

I have ntpd running on the main box. The 1st client server machine I tried is having problems syncing. From the command line I can do;
ntpdate -u 1.1.1.1 (server IP)
8 Aug 14:38:48 ntpdate[31385]: adjust time server 1.1.1.1 offset -0.014469 sec
then to check, I do;
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 48 64 1 0.000 0.000 0.004
m03 .INIT. 16 u - 64 0 0.000 0.000 4000.00

#ntpstat shows
unsynchronised
polling server every 64 s

The client ntp.conf shows;
# A very simple client-only ntp configuration.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
restrict default ignore
restrict 127.0.0.0 mask 255.0.0.0
#authenticate no
server 1.1.1.1

I need to do this on a bunch of machines, and wondering what my 1st thing to check is, as the ntpupdate command line proves that it works right?

Thanks

ntpdate only does a one-time sync. To stay permanently synced you should run ntpd.

when I do restart the client, the ntpstat shows;
unsynchronised
time server re-starting
polling server every 64 s
Interesting though, the messages file on the client shows;
Aug 8 15:02:40 m02 ntpd[1790]: sendto(1.1.1.1): Bad file descriptor
Aug 8 15:03:43 m02 ntpd[1790]: synchronized to LOCAL(0), stratum 10
Aug 8 15:03:43 m02 ntpd[1790]: sendto(1.1.1.): Bad file descriptor

Something in the conf file perhaps?
NM, that part is fixed (2 instances of ntpd running), so now the restart shows it listening, no errors and still unsynchronized.

add the following just below the "server 1.1.1.1":You can use tighter restrictions if you want, but not the default "ignore" that you have.

same result.
The client ntp.conf now shows; (I did comment out the other restrictions and tested both ways)
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
#restrict default ignore
#restrict 127.0.0.0 mask 255.0.0.0
#authenticate no
server 1.1.1.1
restrict 1.1.1.1

Is there anything 'special' the server needs on his end to allow this client to query him? His client section shows;
#restrict 192.168.1.0 mask 255.255.255.0
restrict 1.1.1.0 mask 255.255.255.192

The client machine is on the 1.1.1 network, and at the bottom of that file shows;
restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
server clock.redhat.com
restrict clock.redhat.com mask 255.255.255.255 nomodify notrap noquery

Thanks again

wait....

The client machine has updated a bit, look at this one;

yet /var/log/messages shows;
Aug 8 15:16:41 m02 ntpd[30932]: kernel time sync status 0040
Aug 8 15:19:56 m02 ntpd[30932]: synchronized to LOCAL(0), stratum 10
Aug 8 15:19:58 m02 ntpd[30932]: synchronized to 1.1.1.1, stratum 11

.. but ..

[root@m02 etc]# ntpstat
unsynchronised
polling server every 64 s

getting closer I think!

I think your server (IP address 1.1.1.1) might be synced to its hardware clock. What's the output of
"ntpq -p" on the server?

Well good new / bad news, looks like your right;

The client machine now shows;
[root@m02 etc]# ntpstat
synchronised to NTP server (1.1.1.1) at stratum 12
time correct to within 54 ms
polling server every 64 s

the server shows;
[root@m03 ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) LOCAL(0) 10 l 23 64 377 0.000 0.000 0.001
clock1.redhat.c .INIT. 16 u - 1024 0 0.000 0.000 4000.00

So the client did connect and updated from the server. Now just need to look
at why the server didn't update.

Updated the serer to include 2 local public time servers and now the server updated and the client took the update from the server.

Berhanie, thanks so much for both the prompt replies and advice/solution.

Lance

Good job, Lance.