[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
stenn at ntp.org
Thu Feb 5 20:31:16 UTC 2009
>>> In article <7q7r56-9tb.ln1 at gateway.py.meinberg.de>, Martin Burnicki <martin.burnicki at meinberg.de> writes:
Martin> *only* sends via an unprivileged port if either -q (query only), -u
Martin> (unpriv. port), or -d (debug) is given on the command line.
Harlan> First, given that ntpdate is about to be deprecated in favor of the
Harlan> new SNTP Client, ...
Martin> The topic of this thread is ntpdate vs. ntpd, and I just wanted to
Martin> clarify some statements about ntpdate which are simply wrong.
Yes, and since ntpdate is being deprecated with the replacement being
various combinations of ntpd and sntp I figured we might as well be sure any
desired changes could be accomodated "in the future":
Harlan> ... while this discussion is interesting at face, I see us using
Harlan> this information to guide the bahavior of the sntp code and don't
Harlan> expect to see any changes to ntpdate (especially since there is no
Harlan> maintainer for ntpdate).
Martin> From the discussion here I don't see why any changes should be
Martin> required/requested for ntpdate.
Agreed, but I think we may want to tweak the behavior of sntp.
Harlan> Without thinking about this much, I agree 100% that -u should mean
Harlan> "not from port 123".
Harlan> I can see cases where one *might* want this behavior for -q but I'm
Harlan> not certain it should be forced for -q.
Harlan> I wonder quite a bit more why we would want this behavior for -d.
Harlan> For either of these last two cases it should be trivial to also
Harlan> supply -u if that is what was really desired.
Martin> What I've written corresponds to the behaviour of ntpdate as-is, and
Martin> IMHO this is very useful.
Martin> As I understand this, this is due to the history of ntpdate.
I think so.
Martin> If "ntpdate %host%" was run to set the system time then this worked
Martin> to set the initial system time before ntpd was started but did not
Martin> work if ntpd already had port 123 open.
I think so, too.
Martin> This kind of usage may be obsolete after -g has been introduced for
Martin> ntpd. BTW, why is the beaviour of ntpd -g not the default? IMHO
Martin> this is exactly what users expect from ntpd.
Because ntpd also gets restarted, and there is a strong belief that -g is
bad for a restart and restarts will happen more often than boots.
Martin> Anyway, ntpdate is still very good to debug NTP problems.
And sntp should be able to take over that role.
Martin> You can run ntpdate -q as a quick test to check the time offset
Martin> against a particular server, even if ntpd is running and that server
Martin> is not in ntpd's list. If you want to see more details of the packet
Martin> exchange you can run ntpdate -d. Both commands can easily be used
Martin> without interfering with the running ntpd, and this is mainly
Martin> because they use a different port to send the request.
Makes sense, and "ntpdate -q" is the same as "sntp" and with each you will
get more verbosity/debugging if one supplies -d.
Martin> IMHO programs which do not provide any services should in general
Martin> use random ports by default. ntpdate sending requests via port 123
Martin> is IMHO an exception in order to prevent it from unintentionally
Martin> messing up ntpd. If sntp can also be run as daemon then maybe it
Martin> should use port 123 in daemon mode, but use a random port by default
Martin> in non-daemon mode.
If somebody wants to set the clock using sntp, I'm perfectly fine having it
use port 123 by default and a random port only if -u is provided.
sntp does not at this time have a daemon mode. Max, is this correct?
Since sntp is effectively a new program, I'm OK having a discussion about
exactly what options are appropriate in which circumstances. My preference
is to start from a "clean slate".
Martin> If ntpd is not running you can use ntpdate with and without -u/-d to
Martin> see if a reply from an upstream server is received. This can be
Martin> helpful to find out whether a firewall is blocking no ports / all
Martin> ports / only privileged ports.
Yes, and sntp can be used similarly.
Martin> The problem with ntpdate is that code which is used in several
Martin> programs of the NTP package (ntpd, ntpdate, ntptimeset, ...) has
Martin> been *copied* from one program to another instead of putting it into
Martin> a commonly used source file, e.g. in libntp. Over the years changes
Martin> have been applied to the code in ntpd, but those changes have not
Martin> made their way into the other programs of the package.
Martin> Recently sntp has been written from scratch. So this a pretty new
Martin> code base. However, AFAIK this did not compile e.g. under Windows,
Martin> and in the mean time the author/maintainer has disappeared.
This is the old, msntp implementation. That code also had licensing issues.
Martin> Now gsoc-sntp is there, and I don't see how this could be built
Martin> e.g. under Windows. What I see is that a number of functions which
Martin> are available in ntpd and can be used both under Unix and windows
Martin> have again been duplicated/rewritten in gsoc-sntp. So there is one
Martin> more code base which needs to be ported and maintained. Great.
First, the intent is that gsoc-sntp will build under Windows.
Second, there wasn't time during GSoC to revamp the code tree so a single
common codebase was used. This is something we intend to do, but it will
not happen before 4.2.6 comes out.
There was also a fair amount of discussion about whether or not the sntp
codebase should be completely separate from the ntpd codebase.
My decision was to have them share code whenever possible, and unless I am
convinced the other can of worms is tastier, this is what we'll be doing.
Martin> BTW, the same basic problem is with the ISC libraries, which also
Martin> seem to have been copied e.g. from ISC's bind. Nowadays there a
Martin> different versions of the same source code modules both in libisc/
Martin> and ports/winnt/libisc, e.g. interfaceiter.c, isc_strerror.c, and
This was a mistake IMO, and there should have been a single codebase. I
believe the reason for it is that in the stock ISC libisc/, there are
subdirs for unix/ and win32/ and when Danny(?) did the initial import of
libisc the main codebase was flattened a bit and it contains the Unix code,
and the ports/winnt/ subtree contains the win32/ code.
This should get better when ISC releases libisc as a tearoff/standalone
My intent is to import libisc as a single unit, and this will affect the
build scripts for Windows.
Martin> IMHO this is also quite error prone. E.g. There are 5 (!) instances
Martin> of the isc_interfaceiter_create() function in the code base, 3 below
Martin> libisc/, and 2 below ports/winnt/libisc/.
Yes, this is Bad and it's on the list of things to resolve.
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions