Re: Problems with ntp, ntpdate and chrony
Christoph Bayer wrote:
I'm running Debian 2.2r4 on an Alpha system (noname). I have
almost everything working except an NTP client.
As anybody a working program/configuration?
I am using this combo (ntpdate + ntp) on an Alpha XLT (Alcor) without
any problems, although I am running "Testing" + 2.2.19 kernel here.
I checked my files, and they are almost identical to yours. The main
differences are the actual external time-servers, and the ntpdate
startup line in /etc/init.d/ntpdate is written a bit differently from
yours...it calls a $NTPSERVERS variable stored in
/etc/default/ntp-servers. Here is my line: " /usr/sbin/ntpdate -u -b
-s $NTPSERVERS". Note that mine uses the option "-u". The
/etc/ntp.conf file is identical to yours.
Dunno what could be giving you the problem, but here are some things I
had to "learn" in order to get my setup working.
1. NTPDATE and NTP have different functions. NTPDATE is a "true"
client that will sync your system clock to an external standard no
matter how large the difference in times. NTP is more of a "server" in
that will provide time-synch services to OTHER computers and will keep
in synch with an external time source. Its method of synching to an
external source is different and quite a bit slower. NTP makes use of
the system clock's "drift". It is generally not too good if there are
large differences between your system clock and the external time source
and may take several hours/days to get in reasonable synch.
2. If you are NOT setting up a local "time-server" for your LAN, you
really don't need NTP. NTPDATE will update a single system just fine.
If your system has a LOT of drift, you can run NTPDATE periodically via
a cron job. This is usually not necessary if you re-boot (run NTPDATE)
daily. A lot of this will depend upon the time precision you require.
3. If you are setting up a local time-server, the usual method is to
run NTPDATE first to get the system clock "in the ball-park", then start
NTP and let it keep the synch. On my machine, NTPDATE is run first at
startup in the /etc/rcS/ series of scripts, then NTP is started in the
/etc/rc2.d/ (run-level 2) series of scripts.
4. NTPDATE and NTP cannot be run at the same time! I would suggest
concentrating on getting NTPDATE working before you add in NTP to the
overall problem set.
5. Some external time-servers used for synching are "private" and you
may not have access to them. There is a good listing for these at
http://www.eecis.udel.edu/~mills/ntp/servers.htm. I reviewed the
listing for my area and selected Stratum-2 time-servers that were marked
"public". In any case, it is good practice (courtesy) to let the
sys-admin know you are using their time-server.
6. I had a LOT of initial frustrations getting NTPDATE to work, before
I finally determined that the external time-server I was trying to use
was down! This is an obviouly simple thing, but I overlooked it for
quite a while! Check it out with a ping to see if it is really there
<g>. The IP numbers you used worked for me today...
That is a complete data-dump from here. I wanted a local time-server
for my home LAN, and set this up. Strangely, I had a great deal of
problems getting this going on my IPMasq router (an i386 machine) but
when I moved it to the Alpha, it started working immedialtely. I never
figured that one out ... maybe something to do with the dual
NICS...dunno! All the stuff I "learned" above was on the i386 machine.
I have had absolutely NO problems with the setup on the Alpha.
Sorry for the length....