Problems with ntp, ntpdate and chrony
Christoph Bayer
I'm running Debian 2.2r4 on an Alpha system (noname). I have
almost everything working except an NTP client.
I'm using a kernel version 2.2.19. It must be an Alpha related
problem, I thing the configuration is Ok.
Here is my /etc/ntpd.conf file:
# /etc/ntp.conf, configuration for xntpd
# ntpd will use syslog() if logfile is not defined
#logfile /var/log/ntpd
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 194.25.2.129
server 132.195.20.13
And the ntpdate command during system startup (/etc/init.d/ntpdate) :
/usr/sbin/ntpdate -b -s 194.25.2.129 132.195.20.13
After I did not get ntp/ntpdate to work, I test chrony. But the daemon
dies directly after starting with a SEGV.
As anybody a working program/configuration?
Best regards,
Christoph Bayer
--
To UNSUBSCRIBE, email to debian-alp...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Goswin Brederlow
> Hello everybody,
>
> I'm running Debian 2.2r4 on an Alpha system (noname). I have
> almost everything working except an NTP client.
>
> I'm using a kernel version 2.2.19. It must be an Alpha related
> problem, I thing the configuration is Ok.
Never had problems there.
In what way does it not work? Any error messages? Wrong time?
What does it say if you run ntpdate manually (with more vebose/debug
options)?
All my configs are default.
"dpkg-reconfigure ntpdate" to configure the timeserver for ntpdate
purge and install ntp and let it update its config automatically on
update (alternatively just dpkg-reconfigure it). It will then add a
server line for the timeserver from the ntpdate by itself.
from /var/log/syslog:
Jan 6 20:06:35 alpha ntpdate[347]: step time server 192.168.0.5 offset 0.007705 sec
Jan 6 20:11:22 alpha ntpd[438]: ntpd 4.1.0 Wed Oct 24 04:30:24 MST 2001 (2)
Jan 6 20:11:22 alpha ntpd[438]: precision = 6 usec
Jan 6 20:11:22 alpha ntpd[438]: kernel time discipline status 0040
Jan 6 20:11:23 alpha ntpd[438]: frequency initialized 7.501 from /var/lib/ntp/ntp.drift
MfG
Goswin
Donald R. Spoon
> 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-
Thimo Neubauer
> After I did not get ntp/ntpdate to work, I test chrony. But the daemon
> dies directly after starting with a SEGV.
I encoutered this problem a while ago and filed an RC-bugs to chrony
(see http://bugs.debian.org/chrony). The problem is that the upstream
author hardcoded a clock frequency of 100Hz which is true for i386 but
not for Alpha (1024Hz) and other arches. After doing a quick
"grep 100 *" I gave up trying to fix the problem... IIRC the bugs is
forwarded to upstream.
CU
Thimo
--
Thimo Neubauer <th...@debian.org>
Debian GNU/Linux 3.0 frozen! See http://www.debian.org/ for details
Christoph Bayer
thank you for your answer!
Reading your mail I found the problems of my 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.
Now I have it working too!
> 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.
The -u options tells ntpdate to use an unprivileged port.
After using -u, ntpdate worked!
I read the man page one and the help to ntp once more:
The answers from the ntp daemons came on port 123/udp.
But my firewall did not let any packet in from ports
bellow 1024 :-)
> 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.
I do not stop my computer if not necessary; so I call ntpdate at startup
and than start the ntpd. The drift of the internal clock seens to be quite
big: about 400 sec in one week...
> 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.
It is possible that I want to use it as a ntp server for my LAN in the
near future...
> 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.
Yes!
> 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.
So I did.
> 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.
Thank you very much for this link, I found some good servers there!
> 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-
>
Once more, thank you very much for your complete answer!
Now will have a look at the systemtime tomorrow morning
so I will see if everything is alright!
Best regards,
Christoph
Goswin Brederlow
> On Sat, Jan 05, 2002 at 04:17:59PM +0100, Christoph Bayer wrote:
> > After I did not get ntp/ntpdate to work, I test chrony. But the daemon
> > dies directly after starting with a SEGV.
>
> I encoutered this problem a while ago and filed an RC-bugs to chrony
> (see http://bugs.debian.org/chrony). The problem is that the upstream
> author hardcoded a clock frequency of 100Hz which is true for i386 but
> not for Alpha (1024Hz) and other arches. After doing a quick
or 1200 Hz for some Alphas.
> "grep 100 *" I gave up trying to fix the problem... IIRC the bugs is
> forwarded to upstream.
MfG
Goswin