[ntp:questions] move_fd() causing bad behavior on AIX5.3

Danny Mayer mayer at ntp.isc.org
Sat Nov 24 02:42:21 UTC 2007

brandon.phillips at lmco.com wrote:
> Harlan Stenn wrote:
>> Did you mean bug 604 or 614?  Regardless, both are marked FIXED, and 604 has
>> been VERIFIED.
> Oops, 614 is what I meant.  I did see that it is closed, but the
> comments on it left me with some doubt about whether it had been
> verified on AIX5 specifically.
>> We don't do much testing under AIX because we don't have easy access to a
>> box.

One thing that we could do for you is to make the move_fd() code do
nothing by creating an #ifdef NO_MOVE_FD option so that AIX can specify
to ignore it.

>> An additional approach would be to use some of the assertion stuff in
>> include/ntp_assert.h and see if you can get something to violate an
>> assertion.
> I will take a look at that.  We were interested in NTPv4 for the
> ability to really always slew (tinker step 0) since our software is
> allergic to time stepping.  We may abandon the idea though, due to
> lack of confidence in the maturity of NTPv4 on AIX5.

It is mature but the ideosyncrasies of the AIX implementation of the IP
stacks is causing unnecessary problems.

>> And if you can shed any light on bugs 135, 309, 598, or 716, that would be
>> swell, too.
> 135, 716: still exist.  I had to explicitly compile away IPv6 support
> to resolve the issue.

I think that basically these are the same thing. The real problem here
is that the IPv6 wildcard socket is trying to grab the IPv4 wildcard too
and it's already bound which is what is causing it to fail. This is a
bug in the O/S since it shouldn't be doing that.

> 309: I don't think our setup would hit this so can't comment.

This looks almost identical to #965.

> 598: This is interesting since it also complains about the xntpd IBM
> ships (which we currently use as well).  We have had some issues with
> the clocks jumping back to 0:00...1970 after reboots; I believe we
> finally convinced IBM there was a problem.  The other issues discussed
> in this bug I am not sure about; we'll have to investigate and see if
> they are contributing to time related pecularities.

This is probably an O/S issue where NTP is not able to retrieve or set
the clock properly.


More information about the questions mailing list