Your message dated Tue, 17 Feb 2009 12:26:35 +0200
with message-id <[email protected]>
and subject line Re: [pkg-ntp-maintainers] Bug#513620: Bug#513620: ntp: Please
check for a loopback interface
has caused the Debian Bug report #513620,
regarding ntp: Please check for a loopback interface
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
513620: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513620
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ntp
Version: 1:4.2.4p4+dfsg-8
Severity: wishlist
If you do not have a loopback interface configured then ntp will work and
sync your time, but ntpq will error out and fail to connect to the running
ntp server.
The only other common symptom of a missing loopback that I could find
was that portmap / statd blows up (assuming you even have that installed
to run NFS). NFS isn't your thing, I'm just including it to show that
ntpq is one of the few things that won't work without a loopback and
nothing in Debian provides any error.
Maybe something as simple as in the start of the init.d script, grep the
output of ifconfig for a Loopback and if none found, echo some comment
about ntpq will not work until you add a loopback interface.
Some extra commentary at this blog post
http://vincemulhollon.blogspot.com/2009/01/debian-nfs-root-interface-configuration.html
Its easier than you would expect to end up with no configured loopback on
a NFS-root mounted diskless workstation.
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ntp depends on:
ii adduser 3.110 add and remove users and groups
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libcap1 1:1.10-14 support for getting/setting POSIX.
ii libedit2 2.11~20080614-1 BSD editline and history libraries
ii libncurses5 5.7+20081213-1 shared libraries for terminal hand
ii libssl0.9.8 0.9.8g-15 SSL shared libraries
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii netbase 4.34 Basic TCP/IP networking system
Versions of packages ntp recommends:
ii perl 5.10.0-19 Larry Wall's Practical Extraction
Versions of packages ntp suggests:
ii ntp-doc 1:4.2.4p4+dfsg-8 Network Time Protocol documentatio
-- no debconf information
--- End Message ---
--- Begin Message ---
Kurt Roeckx wrote:
On Sat, Jan 31, 2009 at 04:15:48PM -0600, Vince Mulhollon wrote:
On Sat, Jan 31, 2009 at 07:46:58PM +0100, Kurt Roeckx wrote:
How do you expect "ntpq" to connect to localhost when you didn't
configure it? Note that the manpage clearly states that
localhost is the default.
OK maybe my bug report was not so well written. Sorry about that.
If ntpd can not be contacted by ntpq, perhaps because of "/etc/init.d/ntp
stop" then you get the following error from ntpq when it can not reach
ntpd:
ntpq: read: Connection refused
Here you have a route to localhost, and it replies that it
can't connect.
I am familiar with that error message.
On the other hand, if ntpd is up and running perfectly, but interface lo is
down, such as "ifdown lo", then you get the following error from ntpq when
it can not reach ntpd:
localhost: timed out, nothing received
***Request timed out.
I'm guessing here you don't have a route to localhost, it gets send
to your default gateway, and nothing replies.
As explained, this is not a bug in ntpd, but just the way the network
behaves.
--- End Message ---
