[ntp:questions] Re: Servers just doen't work (after followingthe troubleshooting page)

Danny Mayer mayer at gis.net
Sat Oct 1 02:02:49 UTC 2005


David Schwartz wrote:
> "Danny Mayer" <mayer at gis.net> wrote in message 
> news:433B65DC.4070103 at gis.net...
> 
> 
>>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.
> 

That's exactly what I said. What you are saying is that we need to add 
O/S specific code to work around a problem with the O/S.

The new code gets rid of all that so it's no longer an issue.

> 
>>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.
> 

That was true before I touched the code. I started to work on it during 
development of 4.2.0.

Danny

>     DS
> 
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list