Christoph Bayer wrote:
Hello everybody, I'm running Debian 2.2r4 on an Alpha system (noname). I have almost everything working except an NTP client. --snip-- < As anybody a working program/configuration? Best regards, Christoph Bayer
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.... Cheers, -Don Spoon-