Re: Servers just doen't work (after followingthe troubleshooting page)


"Danny Mayer" <mayer@xxxxxxx> wrote in message
news:433B65DC.4070103@xxxxxxxxxx

> David Schwartz wrote:

>> Right. And this is a Linux-specific bug, caused by the way NTP
>> decides what interfaces to bind to *on* *Linux*.

> That's actually an incorrect assessment. There is no Linux specific code
> in that area of the code. It does have to do with the way Linux responds
> to certain network function calls that used to result in it using the
> wildcard socket. This no longer happens in the recent releases of the
> development version. If it does it's a bug.

No, the assessment is correct. If Linux responds differently to network
calls but the code that could fix that difference contains no Linux-specific
code, you wind up with a Linux-specific bug.

> We cannot be responsible for what Redhat or any other vendor does with the
> code.

That is true, but RedHat had to do something to fix the problem.
However, changing the behavior of a flag to its opposite was probably a bad
choice. Changing the default and adding a new flag to get the default back
would have been better.

>> Of course, but that's broken design. The effect of listening on
>> "virtual IPs" or what constitues a virtual IP is a platform-specific
>> thing. The flag should specify what NTP does, not how it does it. If it's
>> going to be a platform-specific flag, it should be carefully arranged so
>> that specifying *no* platform-specific flags gets you as close to the
>> same behavior on all platforms.

> The effect of -L is to listen on just the first IP address of the network
> hardware interface for each interface that it encounters. So if you have
> an eth0 and an eth1 interface it will use just the first address of eth0
> and the first address of eth1. It will always use the loopback addresses,
> no matter what you specify.

> It is NOT a platform-specific flag. If vendors use it for other purposes
> then we cannot do anything about that. You can always use the reference
> implementation can get what you need.

It is a platform-specific flag if the *effect* of binding to virtual
interfaces is different on different platforms.

For example, suppose that NTP had code on FreeBSD to correctly determine
the target address even if the socket was only bound to the wildcard address
but there was no such code on Linux. The *effect* of not binding to virtual
addresses then would be very different on Linux than it is on FreeBSD. So
while the flag does the same internal thing to NTP, it has vastly different
effects on different platforms.

The meaning of an option is what effect it has, not what internal detail
it changes.

That's why it is nonsense to say things like "NTP, by default, binds to
<all/no> virtual interfaces". That is a technical internal detail, and if
that same detail results in different effects, then NTP is broken. NTO
should provide the same effect, by default, on all platforms. If it has to
do different things to get the same effect because Linux responds
differently to some network functions, then it should do those different
things by default. Otherwise, it has a Linux-specific bug.

In any event, I'm glad to hear that NTP now does provide the same
behavior by default on all platforms. Thanks for the good work.

DS


.

Relevant Pages

  • Re: Servers just doent work (after followingthe troubleshooting page)
    ... It does have to do with the way Linux responds to certain network function calls that used to result in it using the wildcard socket. ... Changing the default and adding a new flag to get the default back would have been better. ... If it's going to be a platform-specific flag, it should be carefully arranged so that specifying *no* platform-specific flags gets you as close to the same behavior on all platforms. ... It is a platform-specific flag if the *effect* of binding to virtual interfaces is different on different platforms. ...
    (comp.protocols.time.ntp)
  • Re: Monitoring the leap second tonight
    ... While the kernel does step the clock backward, the clock reading routine should remember the last reading and not allow a backward adjustment, unless more than two seconds. ... As for the leap itself, all the radios, FreeBSDs, Solariba, Ultrax and Alphae leaped the leap correctly. ... The CDMA receiver with embedded Linux went bonkers; it took the leap 24 hours ago and stayed that way until after the leap tonight. ... I'm not sure what this means; the CDMA takes its cue from GPS and the CDMA receiver hands off to NTP. ...
    (comp.protocols.time.ntp)
  • Re: Garbage in Refid field - peers
    ... > TJ Horlacher wrote: ... >>>On the contrary, upgrade ntp on Linux. ... win servers using 4.0.2b but not 4.0.2a... ...
    (comp.protocols.time.ntp)
  • Problem with Linux Machines Request for Time from an XP Machine
    ... The Linux modem is only there to conduct tests regarding the problem I present ... I believe this is time kept by NTP (see comment just above ... I deliberately set the clock off by 15 seconds in Linux. ... Your personal or network firewall prevents clock synchronization. ...
    (comp.os.linux.networking)
  • Re: Setting Up NTP for Time Sync
    ... >>Why can't I synch off of the NTP machine from linux? ... >>I deliberately set the clock off by 15 seconds. ... Your personal or network firewall prevents clock synchronization. ...
    (comp.os.linux.networking)