NTP configuration problem

is ntpd running? then the socket is in use, and the message is ok.
If ntpd is running, what's your prblem then?

ntpd is running, however the clock is not being synchronized.  In fact, the local clock is off by 6 hours and 58 minutes.

there is a limit for ntpd when it will not adjust the clock, AFAIK it's 1000 sec. You should see a corresponding message in the log files.
In this case you need to set your clock first with date and/or hwclock.

My clock was set to nearby the correct time. However, it still appears that ntp is not synchronizing properly.

The NTP server is a known good one (other clients can successfully connect to it...).

Hopefully this output may help:
[root@linus rc3.d]# ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.0.23.1       0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00
ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 64196  8000   yes   yes  none    reject

what is in your log files?

hello--which log files would you like?

/var/log/{messages,ntp}

Using a different ntp.conf here, I still am unable to successfully sync my time, it appears:

#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  10.0.23.1       # local clock
fudge   10.0.23.1 stratum 10

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

#
# Authentication delay.  If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
authenticate no

#
# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
#keys           /etc/ntp/keys


From my /var/log/messages:
Jun 13 11:16:57 linus ntpd: ntpd startup succeeded
Jun 13 11:16:57 linus ntpd[21743]: precision = 33 usec
Jun 13 11:16:57 linus ntpd[21743]: kernel time discipline status 0040
Jun 13 11:16:57 linus ntpd[21743]: 10.0.23.1 is inappropriate address for the fudge command, line ignored
Jun 13 11:16:57 linus ntpd[21743]: frequency initialized 0.000 from /etc/ntp/drift
Jun 13 11:16:57 linus ntpd[21743]: bind() fd 8, family 2, port 123, addr 224.0.1.1, in_classd=1 flags=0 fails: Address already in use
Jun 13 11:16:57 linus ntpd[21743]: ...multicast address 224.0.1.1 using wildcard socket

There is no /var/log/ntp

> Jun 13 11:16:57 linus ntpd[21743]: 10.0.23.1 is inappropriate address for the fudge command, line ignored

Well, simply fix this, and it should work ;-)

I've commented out the fudge line and it still doesn't work.  

*sigh*

please print result of:
awk '($1 !~ /^#/){print}' /etc/ntp.conf

Result:

server  10.0.23.1       # local clock

driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

authenticate no

do you have a multicast enabled kernel?
Do you know what the multicastclient really does?
I'd remove the multicastclient setting.

Can you reach the specified server?
what does ntpdate report now?

I don't think I have multicast enabled kernel..how would I find out?

Other PCs can sync to the server just fine.

ntpdate output:
[root@linus root]# ntpdate
25 Jul 10:03:50 ntpdate[28437]: no servers can be used, exiting

Note: I haven't seem to get ntpdate on Linux/SGIs systems to ever work.  So far, I've gotten only ntpq to report statistics back.

Out of curiosity, could I possibly have a firewall up that is blocking a port that NTP needs? If so, how can I determine whether a firewall is preventing connections?

ok, the ntpdate output is different now.
The firewall might be a problem, you need to allow port 123 UDP in both directions

i'm new to linux firewalls...how do i check to see how my firewall's ports are configured?

iptables -L -n && iptables -L -n -t nat

or

ipchains -L -n

Is this a good sign? If not, how would I go about fixing this?

Thanks so far.

# ipchains -L -n
Chain input (policy ACCEPT):
target     prot opt     source                destination           ports
ACCEPT     udp  ------  10.0.20.10           0.0.0.0/0             53 ->   1025:65535
ACCEPT     udp  ------  10.0.13.14           0.0.0.0/0             53 ->   1025:65535
ACCEPT     udp  ------  10.0.23.34           0.0.0.0/0             53 ->   1025:65535
ACCEPT     tcp  -y----  0.0.0.0/0            0.0.0.0/0             * ->   80
ACCEPT     tcp  -y----  0.0.0.0/0            0.0.0.0/0             * ->   22
ACCEPT     all  ------  0.0.0.0/0            0.0.0.0/0             n/a
REJECT     tcp  -y----  0.0.0.0/0            0.0.0.0/0             * ->   0:1023
REJECT     tcp  -y----  0.0.0.0/0            0.0.0.0/0             * ->   2049
REJECT     udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   0:1023
REJECT     udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   2049
REJECT     tcp  -y----  0.0.0.0/0            0.0.0.0/0             * ->   6000:6009
REJECT     tcp  -y----  0.0.0.0/0            0.0.0.0/0             * ->   7100
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

peyo:
This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
EXPERTS:
Post your closing recommendations!  No comment means you don't care.